今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net

[過去ﾛｸﾞ] 今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

353(1): 2018/02/04(日)16:51 ID:i7LhZGzA(1) AAS
あえて言おう、女子小学生と！

354: 2018/02/04(日)17:03 ID:Oj6myZBS(1) AAS
AA省

355: 2018/02/04(日)17:50 ID:z6WochWF(1) AAS
逮捕！

356: 2018/02/04(日)17:54 ID:/nA3Cux+(1) AAS
>>350
大半が同じ感想のはず。
ajaxの手法が公開されてから一気に沸騰した。

357: 2018/02/04(日)19:07 ID:m27l3Bxn(1) AAS
JK=ジャパニーズ・コリアンニダ！

358: 2018/02/04(日)20:49 ID:bJ63O2JQ(1) AAS
The Wine development release 3.1 is now available.

What's new in this release (see below for details):
- Kerberos authentication support.
- Window class redirection for Common Controls 6.
- Support for X11 ARGB visuals.
- DOSBox required for running DOS executables.
- Various bug fixes.

359: 2018/02/05(月)02:08 ID:O1Pwqk/s(1) AAS
とりあえず3.0stableで様子見決め込んでる

360: 2018/02/05(月)19:21 ID:Nv69ARvL(1) AAS
wine-staging2.21からwine-stable3.0にしたら
負荷とメモリ消費が素晴らしく改善されたから
開発版に手を出しかねてる

3.0で改善されたのか、stagingのものが足を引っ張ってたのか判別つかなくて

361: 2018/02/05(月)20:00 ID:EoTMajD6(1) AAS
chrootで試せばいい。

362: 2018/02/07(水)03:18 ID:EaQ8LavF(1) AAS
janeで書き込みてすと

363: 2018/02/07(水)11:19 ID:wf+3Oqyn(1) AAS
3.4のときは起動すらしなかったのにな
4.0になったら快調すぎる

364: 2018/02/07(水)12:09 ID:obK+oDJv(1) AAS
だったらいいんjane

365: 2018/02/07(水)13:18 ID:zs43/D2L(1) AAS
じゃあコンパイルすっかな

366: 2018/02/08(木)05:29 ID:awGx+2l1(1) AAS
結局のところwinehq-stableとwine-stableの差は何なのさ

367: 2018/02/09(金)02:10 ID:7CcbsDfN(1) AAS
winehq stableが公式サイトで公開されてるやつでwine stableは各ディストリから配布されてるやつだと思ってたけど違うのかな

368(1): 2018/02/09(金)09:15 ID:VkWK7O5C(1/2) AAS
wine-3.1-arm.apk
ExaGearより動くかなと期待して入れたんだけど、プログラムが一つも動かない…
まだ見てくれだけの未完成品ってこと？

369: [ｓａｇｅ] 2018/02/09(金)09:31 ID:VkWK7O5C(2/2) AAS
あー　Windows RT ARMのソフトしか動かないのかこれ

370(1): 2018/02/09(金)10:40 ID:PPTatEc4(1) AAS
違うだろ

2chｽﾚ:market

371(1): 2018/02/09(金)10:58 ID:FuNSphmo(1) AAS
>>370
マルチポストにつきNG推奨

372: 2018/02/09(金)11:54 ID:uGFZgCuz(1) AAS
>>371
こいつMac関連のスレ狙ってる？別にそんな事ないのかな

373(1): 2018/02/10(土)14:13 ID:JX1fd7td(1/2) AAS
crossoverのベースになっているwineのバージョンってどこから調べたらいいの？
もう3.0ベースになってるのかな

374(1): 2018/02/10(土)21:57 ID:yxHJfpP2(1/2) AAS
>>373
/opt/cxoffice/changelog.txt
もしくは
外部ﾘﾝｸ:www.codeweavers.com

3.0はまだやね

375(1): 2018/02/10(土)22:08 ID:yxHJfpP2(2/2) AAS
ちがったかな
$ /opt/cxoffice/bin/wineserver --version
wine-2.8-8251-g8a457d1

376: 2018/02/10(土)23:24 ID:JX1fd7td(2/2) AAS
>>374-375
ありがとう
そっかまだかあ

377: 2018/02/15(木)16:28 ID:Adu/G50n(1) AAS
ubuntu studio 16.04LTS にwineを入れて、
JaneStyle を使える様にはなった。
書き込みテスト。

378: 2018/02/15(木)22:20 ID:feRq4tDS(1) AAS
>>368
まじかよ、Elonaさえ動けばいいのに。

379: 2018/02/15(木)23:40 ID:XEMKL93X(1) AAS
ARM機とかスマホしか持ってないわ
これから増えるんかね

380: 2018/02/16(金)01:05 ID:+Lqzmf2v(1) AAS
3DSとかもARMじゃないっけ

381: 2018/02/16(金)08:01 ID:TwuYLqrN(1) AAS
PS VitaもARMだしSwitchもARMだな

382: 2018/02/16(金)08:03 ID:8cWV/uet(1) AAS
最近のモバイル端末はだいたいARMだな

383: 2018/02/16(金)08:03 ID:8uACRqcY(1) AAS
ChromebookもARM機ある

384: 2018/02/16(金)11:10 ID:80vLUCQ5(1/2) AAS
WindowsもARM機が再登場する

385(1): 2018/02/16(金)12:08 ID:Q5rpQjEk(1) AAS
RTでコケて痛い目にあったからそれはないと思う。
ARMじゃない別のアーキテクチャで出す可能性はあるかも・・・
そしてまたコケるw

386: 2018/02/16(金)12:24 ID:Pj9ij8xw(1) AAS
>>385
いや出るから
HPとASUSがsnapdragon搭載Windows端末を発表済で春に発売予定

387: 2018/02/16(金)13:41 ID:QNuqSD5T(1) AAS
売れるとは限らないんだがなぁ
x86exeが何となくでも動くだけでいいのにな

388: 2018/02/16(金)15:27 ID:80vLUCQ5(2/2) AAS
x86が動くWin10のARMが出る

389: 2018/02/16(金)16:20 ID:1h3N4gI+(1) AAS
ちょっと調べてから否定しようよ
まあいいんだけどさ

390: 2018/02/16(金)19:29 ID:XuFK7/QF(1/4) AAS
古いけど、Ubuntu12.01 への Wine3.0のインストールに成功した。
git のソースから、./configure
途中、Font関連のファイルが見つからないエラーが出たので、
そのFontの「dev版」をapt-getでインストール。
その他、いくつかエラーが出るので、インストールしたりする。
その後、make, make install。
でインストールには成功するが、今まで動いていたWinアプリを起動してみると
日本語で文字化けしてる。wintricks font や regedit などをいじってみたが、
ダメだった。しかし、apt-get remove wineとしたあと、再度、
apt-get install wineとすると、なぜか、すぐに成功した。
省3

391: 2018/02/16(金)19:30 ID:XuFK7/QF(2/4) AAS
3.1じゃなく、3.0でした。スマソ

392: 2018/02/16(金)19:37 ID:XuFK7/QF(3/4) AAS
Wzエディタで、検索やGrepのダイアログのStatic Textの表示が途切れてしまう
不具合があったのが、Wine3.0では修正されている。これは使える。

393: 2018/02/16(金)23:10 ID:XuFK7/QF(4/4) AAS
透明色と MDI Window を組み合わせた自作WindowsアプリをWineで動くように修正中。
MDI Child Widnow のタイトルバーをドラッグすると遅くなるので原因を調査していた。
PreTranslateMessage() にくるメッセージを、自前でWindowに表示していたところ、
システム全体が実質的にハングアップした。マウスは動くが、タスクバーも反応しない。

ちなみに、透明色とMDI Windowの組み合わせが必ず遅くなるわけではない事は、
単純なテストプログラムを作って分かっている。ではなぜ、このプログラムに限っては
遅くなるのかが分からないので調査中だった。

394: 2018/02/17(土)14:20 ID:SLFwTllY(1) AAS
The Wine development release 3.2 is now available.

What's new in this release (see below for details):
- Separate implementation of USER controls for ComCtl32 v6.
- Multisample texture support in Direct3D.
- Support for HID gamepads.
- More event support in MSHTML.
- Obsolete DOS code removed.
- Various bug fixes.

395: 2018/02/17(土)16:25 ID:XDWn7PKv(1) AAS
廃れたDOSコードを削除、か

396(60): 2018/02/17(土)16:26 ID:KjUUJ1nJ(1/9) AAS
Wineは、Desktopの直接の子であるような、Win32における「OVERLAPED WINDOW」
的な物しか、XWindow の Window を作らないのだろうか？？
Wineのソースをダウンロードして、FIXME(WARNでもいいはずだけど)で実行を調べてみた。
でも、良く分からない。ビルドとmake installに時間がかかるため、大変。
本当はもっと実験したいんだけど、時間的に難しくなる。

ソースを見ると、HWNDの親が Desktopの場合にだけ、XCreateWindowしているように
見える。これが、透明ウィンドウが遅くなる理由かもしれない。LinuxのNativeなWindowの
場合、実験した限り透明にしても速度が余り変わらない。でも、Wineがもし、自前で透明処理
をやっているとなれば遅くなるのも頷けるが。

1つのソースしか修正してないのに、ビルドが始まるまでに数十秒かかる。make installに
省2

397(1): 2018/02/17(土)16:41 ID:eqmjcJnH(1/2) AAS
>>396
>ソースを見ると
どこだかわからんから外部ﾘﾝｸ:source.winehq.orgのリンク貼ってくれ

398: 2018/02/17(土)17:12 ID:KjUUJ1nJ(2/9) AAS
>>397
今回に関しては、以下を読んで、git でやってます :
外部ﾘﾝｸ:wiki.winehq.org

home directory (~) にて、
$ git clone git://source.winehq.org/git/wine.git [ret]
とすると、wine ディレクトリが作成されるので、
$ cd wine
とします。そこで、
$ git config remote.origin.url [ret]
と入れて
省12

399: 2018/02/17(土)17:16 ID:KjUUJ1nJ(3/9) AAS
5ch からのアクセスは禁止されているらしいので、アドレスバーに上記の URL を
コピーしてアクセスしてください。

なお、make が遅い件は、make -j 4 などとして、マルチコア動作するとだいぶ良くなりました。
ただし、その場合、make にバグがあるので精密な神経の持ち主には、ストレスがたまります。

400: 2018/02/17(土)17:19 ID:KjUUJ1nJ(4/9) AAS
動きをトレースしたい場合、TRACE はデフォルトではメッセージが出ず、使い方を調べて
ないので、

FIXME( "Yamada Taro, CreateWindowEx, hWND=%08X", hWND );

みたいにやってます。

401: 2018/02/17(土)17:23 ID:KjUUJ1nJ(5/9) AAS
makeしたい人は、~/wine にて、

$ ./confiugre
$ make -j 4 2>build.log
$ make -j 4 install 2>inst.log
$ wineserver -k

で行けます。ここで、wz エディタを起動してみます。文字化けするようでしたら、

$ apt-get remove wine
$ apt-get install wine

で直ると思います。これは、一度やれば Ok のようです。

402(1): 2018/02/17(土)17:40 ID:KjUUJ1nJ(6/9) AAS
AA省

403: 2018/02/17(土)17:41 ID:KjUUJ1nJ(7/9) AAS
AA省

404: 2018/02/17(土)17:42 ID:KjUUJ1nJ(8/9) AAS
AA省

405: 2018/02/17(土)18:08 ID:KjUUJ1nJ(9/9) AAS
ちなみに、
1. ~/.wine
2. ~/wine

は別物です。1は、binary をインストールした際に出来るデフォルトのフォルダ
ですよね。2. は、git からソースを持ってきた時にできるディレクトリです。

まずは、バイナリをインストールして動作してから、ソースを持ってきてください。

406(4): 2018/02/17(土)18:27 ID:1JDlaACg(1) AAS
半透明化はWin32API側でどうやっているの? Linuxネイティブなアプリでは?

SetLayeredWindowAttributesであれば、user32.dllからUSER_Driverを介してwinex11.drvが呼ばれて、
window.c内のsync_window_opacityで_NET_WM_WINDOW_OPACITYにα値を設定している様子が見て取れる
外部ﾘﾝｸ[c]:github.com

TRACEで表示しているメッセージを確認するには環境変数WINEDEBUGを使って、
WINEDEBUG=win,x11 みたいにカンマ区切りで指定する。細かくは
外部ﾘﾝｸ:wiki.winehq.org に書いてある。

あとは、dlls配下の各ディレクトリでもmake && sudo make instlallできるので
特定のDLLファイルしか変更しないのであれば、この方法でビルド時間を短縮できるぞ。

407: 2018/02/17(土)18:42 ID:cvAP0C15(1/2) AAS
デバッグ大変だな。めんどくさそう。
仕事じゃないと俺はやらないだろうな。

408: 2018/02/17(土)19:41 ID:J9G7l4mf(1) AAS
自分はimm32関連(日本語入力)APIを修正しようとeclipceでコンパイル環境作ったはいいけど
ネイティブのウィンドウマネージャ関連の知識不足でソースの意味がわからず寝かせてある・・・

409(1): 2018/02/17(土)19:54 ID:Tf7u8zkg(1/4) AAS
>>406
Linux Nativeアプリの場合、32BIT COLOR にすると、A,R,G,B の 4つの値を
ドットの「色」として指定できます。Aがα値です。このようなことは、Windows
では出来ないと思います。Windowsの場合、CreateWindowExのdwExStyle に
WS_EX_LAYEREDを指定すると透明、半透明が扱えるようになります。

1.完全に「透明になる色」を24BIT値で1色指定できます。この色で描いたドットは、
　デスクトップまで透けて見えるようになります。見た目だけではなく、Windowメッ
　セージも下のWindowに伝達されてしまうことになりますが。

2.ドットごとではなく、Window全体のα値を1つ(1BYTE)だけ指定できます。
　ドットごとでは無いので、全体的に透明度が決まってしまいます。
省3

410(1): 2018/02/17(土)19:57 ID:Tf7u8zkg(2/4) AAS
/wine/dlls/winex11.drv/x11drv.h
に次のような構造体があり、この whole_window というのが大事らしい：
/* x11drv private window data */
struct x11drv_win_data {
Display *display; /* display connection for the thread owning the window */
XVisualInfo vis; /* X visual used by this window */
Colormap colormap; /* colormap if non-default visual */
HWND hwnd; /* hwnd that this private data belongs to */
Window whole_window; /* X window for the complete window */
Window client_window; /* X window for the client area */
省21

411: 2018/02/17(土)20:00 ID:Tf7u8zkg(3/4) AAS
>>406
後半の二つ。自分に取っては、かなり貴重な情報です。助かります。

412: 2018/02/17(土)20:11 ID:Tf7u8zkg(4/4) AAS
>>406
XWindow で透明化。これはやってみて実際に出来ました：
外部ﾘﾝｸ:stackoverflow.com
how-to-create-semi-transparent-white-window-in-xlib

子ウィンドウを入れてみても、ちゃんと出来ました。

ただし、子ウィンドウには、Win32のような、タイトルバーは付ききませんでした。
XWindow に詳しい人によれば、XWindow の Window Manager は、
Win32 の MDI のような事は、サポートしていないらしいです。絶対か
どうかは分かりませんが。

実験してみると、子ウィンドウも、親ウィンドウも、ABI で、XMoveWindow
省3

413: 2018/02/17(土)21:31 ID:cvAP0C15(2/2) AAS
Win32APIだけじゃなく、X Windowについても知っておかないといけないのか
面倒臭っ・・・

普段使ってるだけでずいぶん楽してたんだな。

414: 2018/02/17(土)22:08 ID:eqmjcJnH(2/2) AAS
面白そうだけど時間ねえな……
>>410を見る限りだとuse_alphaは持ってるけどAlpha値自体はもうX11の構造体にいれてるのかな？
まあ遅くなる理由とか検討つかんけど……

415(3): 396 2018/02/18(日)01:13 ID:DznsC7ZZ(1) AAS
WINEにおいて、

1. MDIのCMDIChildWndのCViewのCLIENT領域全体(子ウィンドウの
　中全体と言ってもよい) に >>409の1.の色を塗って、完全透明
　にしている時は、CMDIChildWndのタイトルバー(子ウィンドウの
　タイトルバー）をドラッグしても高速に動かせる。

2. 1のCViewの中に、pDC->LineTo()で直線を一本描いた状態にしてから
　同じ事をしようとすると、とても遅くなる。

3. 2.は、直線の代わりに pDC->TextOut() で文字を描いても同様に遅く
　なる。

4. 推定では、Wineは、Win32のCreateWindow系で、Parent Window が
省11

416(1): 2018/02/18(日)01:24 ID:smHwezpH(1) AAS
推定じゃなくて直接聞いたら？

417: 2018/02/18(日)01:56 ID:HH6qVqdM(1/9) AAS
>>416
どうやって？

418(3): 406 2018/02/18(日)02:29 ID:dARugMLm(1/2) AAS
>>415
すまん、ウィンドウの半透明化処理(LWA_ALPHA)と勘違いしてた。
ウィンドウ領域内の特定色で書いた箇所を透過させる場合(LWA_COLORKEY)ね。

ソースを調べたら、WineではX11のShape Extensionを使ってウィンドウの形状を変更することで、
「見た目だけではなく、Windowメッセージも下のWindowに伝達すること」を実現しているようだ。

具体的にはupdate_surface_region()で1ピクセルごとにピクセル値を比較して、
XShapeCombineRectanglesに指定する矩形領域を作っている。
外部ﾘﾝｸ[c]:github.com

415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。
省1

419: 2018/02/18(日)04:20 ID:HH6qVqdM(2/9) AAS
>>418
なるほど。

1つ質問です。

はっきりとは書いてなかったのですが、>>415の遅くなる条件であるところの 2,3 の場合
においても、CMainFrame、つまり、アプリケーション全体の Main の Window のタイトルバーを
ドラッグした場合は、遅くなりません。いたって高速にドラッグできます。

>>418 が正しいなら、どうして、X は、この場合だけは速く、CMDIChildWnd の場合だけは
遅く動作するのでしょうか？？？

420(1): 2018/02/18(日)04:57 ID:HH6qVqdM(3/9) AAS
AA省

421: 2018/02/18(日)05:32 ID:HH6qVqdM(4/9) AAS
/wine/dlls/user32/painting.c の中の、
// Set the visible region and X11 drawable for the DC associated to a given window.
static void update_visible_region( struct dce *dce )
の中に、
USER_Driver->pGetDC( dce->hdc, dce->hwnd, top_win, &win_rect, &top_rect, flags );
とあって、
void CDECL X11DRV_GetDC( HDC hdc, HWND hwnd, HWND top, const RECT *win_rect,
const RECT *top_rect, DWORD flags )
が呼び出される。引数に hwnd と top、win_rect と top_rect が対になっているらしいことに注意。

この関数の中で、x11drv_escape_set_drawable escape; の
省17

422(1): 2018/02/18(日)12:58 ID:HH6qVqdM(5/9) AAS
結論的には、Wine では、完全透明色が設定されている全ての LAYERED_WINDOW に
対して、Idle状態の時か、または、50(ms) 毎に、Windowアプリのメッセージループ
の中から自動的に、>>418 の update_surface_region() が呼び出されるようになっ
ているらしいです。この条件のWindowがあって、かつ、update_surface_region() の
処理が重い場合に、動作が遅くなる可能性が高いです。Dirty Bitのようなものは、
今のところ見つかっていませんので、何もしなくても常に重くなるのでしょうか。

【詳細】
flush_window_surfaces() なる関数が、定期的に呼び出される。
典型的なタイミングは、PeekMessage() の中からであり、GetMessage()では、
check_for_driver_events() を介して呼び出される。
省16

423: 396=422 2018/02/18(日)13:53 ID:HH6qVqdM(6/9) AAS
該当の条件の時、新たには何の描画もしていない静止状態でも、Linuxのシステム・モニターで
CPUパワーが膨大に消費されていることを確認しました。このことは、>>422 を裏付ける物です。
だとすると、Dirty Bit を導入して、update_surface_region()の頻度を下げれば、この低速化
は修正できる可能性が出てきました。LineTo, TextOut, MoveWindow, SetWindowPos,
ShowWindow などを使ったときだけ、DirtyBit を 1にして、1の時だけ update_surface_region()
を呼び出し、呼び出した後には 0 にすれば良いのではないかということです。

条件は：

1. WINEを使用して Windowsアプリを走らせていること。
2. アプリ内で CreateWindowEx() のdwExStyle に WS_EX_LAYERED を指定して Windowを作成
　済みであること。
省9

424: 396 2018/02/18(日)14:19 ID:HH6qVqdM(7/9) AAS
>>418 さんの指摘は凄く役立ちました。有難うございます。

ただし、こっちの調査不足のせいが大きいのでしょうが、以下の部分は、今回の
結果とは違っていたようです：
>415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
>矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。

「X側の描画性能の低下」が原因ではなく、「ピクセル値を比較する処理」自体が、
実は「静止状態」でも、常時、大幅に増加していた、ということです。

何の変化がないときにでも、百万ピクセルを比較し、ランレングスを導き出す処理を、
原則的には秒間20回もやっています。

また、図形が複雑だと、システムコールを呼び出す回数がランレングスの変化の回数倍
省7

425(2): 396 2018/02/18(日)14:38 ID:HH6qVqdM(8/9) AAS
【厳密化】

1. 多分、6,000回ではなく、4,500回程度でした。
2. 比較処理自体は、図形の複雑さとは無関係にほぼ一定の重さです。
3. 図形が複雑な場合、システムコールの回数が増えます。
4. 横方向の1つのランレングスで、3つのシステムコールが呼ばれます。
5. 図形が何も描かれていない場合、1つのy座標に対して、1つのランレングスです。
6. N 本の直線の場合、大体で言えば、3N 個のランレングスになります。
7. だから、1つのy座標に対し、9N 個のシステムコールが呼ばれることになります。
8. 縦 500 ドットの場合、500*9N = 4500 N 回のシステムコールとなります。
9. よって、中に描かれている直線の本数が増えると、大体 O(N) で処理時間が
省2

426: 396 2018/02/18(日)15:25 ID:HH6qVqdM(9/9) AAS
>>425
【訂正】
「6.」のランレングスの個数は、3N個ではなく、2N+1 個でした。

お騒がせしました。

427(2): 2018/02/18(日)16:08 ID:dARugMLm(2/2) AAS
>>425
update_surface_regionの方が効率悪そうなので、X側の描画性能が原因と推測した部分は撤回する。

Shape Extensionの仕様を見ると、
矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。

あと、MDIウィンドウがXのWindowではないことは、xwininfoコマンドの結果でも確認できる。

428(1): 396 2018/02/18(日)17:01 ID:hqeoLLBF(1) AAS
>>427
>矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
>BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。

少なくともその方法だと、図形の複雑さによらずに安定して同じ処理時間で
済みますね。それと当然、BitBlt はハードウェアの補助が得られます。
あと、システムコールも全体で数回しか呼ばなて済みますし。

429: 396 2018/02/19(月)12:40 ID:v4nZjJQ1(1/2) AAS
特定のアプリの場合にだけは、自作の user32.dll.so を読み込ませる事が出来ない。
WINEDLLPATH, WINEPATH を試してみたが、今のところ上手く行かない。

430: 396 2018/02/19(月)15:28 ID:v4nZjJQ1(2/2) AAS
調べてみると、/wine/libs/wine/loader.c の中の build_dll_path()
関数の中で、環境変数 WINEDLLPATH が、読み取られ、: を 0x00に
変えてから、dll_paths[] 配列に : で区切られたそれぞれの文字列
の先頭アドレスを代入している。

しかし、その処理に入る前に、get_dlldir() 関数が NULL 以外を返した場合、
dll_paths[0] にその関数が返した文字列のアドレスを入れてしまう。

そして、実際の get_dlldir() は、"/usr/local/bin/../lib/wine"
という文字列を返してくるので、そっちのパスの方が、WINEDLLPATH
の優先順位よりも上になってしまう。そして、

/* retrieve the default dll dir */
省10

431: 2018/02/19(月)15:47 ID:qkc2SRTD(1) AAS
見つかりました。wine/libs/wine/Makefileの中で、
config_EXTRADEFS = \
　　-DBINDIR='"${bindir}"' \
　　-DDLLDIR='"${dlldir}"' \
　　-DLIB_TO_BINDIR=\"`$(MAKEDEP) -R ${libdir} ${bindir}`\" \
　　-DLIB_TO_DLLDIR=\"`$(MAKEDEP) -R ${libdir} ${dlldir}`\" \
　　-DBIN_TO_DLLDIR=\"`$(MAKEDEP) -R ${bindir} ${dlldir}`\" \
　　-DBIN_TO_DATADIR=\"`$(MAKEDEP) -R ${bindir} ${datadir}/wine`\"
というのが。単語検索していたのが鬼門でした。

432: 396 2018/02/19(月)19:22 ID:WuPPo4Ry(1) AAS
loader.c の build_dll_path() の修正と、user32.dll.so の修正を、
自分のアプリだけに適用する事に成功しました。

433(1): 396 2018/02/20(火)03:10 ID:nCkYsCc8(1/4) AAS
surface が NULL ではない場合、xxx->pLineTo() は、X11DRV_LineTo()
ではなく、dibdrv_LineTo() が呼び出されるような・・・。

434: 396 2018/02/20(火)05:59 ID:nCkYsCc8(2/4) AAS
DirtyBit を使って、例の update_surface_region() は、
描画してないときには全く呼ばれないようにできたんですが、
まだかなり遅いです。何もしてないときにも CPU パワーがかなり消費されています。
その間、update_surface_region() が呼び出されていないことは、FIXME で
表示して確認が取れています。

なお、>>433は、windrv_LineTo() の方の間違いでした。windrv_LineTo() の場合、
簡単に surface にアクセスできるので、surface に bNeedToUpdate のような
フラグを追加して、それを 1 にして dirty bit にしています。

なぜ遅いままなのかは謎です。

435: 2018/02/20(火)06:05 ID:AmaI1OSV(1) AAS
2ch(5ch?)は人は多いけど基本的にユーザーレベルの人ばかりだから技術的な書き込みしても反応は鈍いね
Qiitaにでも書いてみたらどう？

436(1): 2018/02/20(火)18:28 ID:QMmYbOOf(1) AAS
本家にパッチ投稿もお願いしますw

437: 396 2018/02/20(火)18:49 ID:nCkYsCc8(3/4) AAS
遅い原因の1つは、Onldle の中にあることが分かりました。

1. 必要があって、外部ツールによるファイルの更新チェックをしていたところ、
　それがとんでもなく重い事が判明。

2. SetTimer で CMainFrame にタイマーをしかけていると、CMainFrame::OnCmdMsg()
　が、WM_TIMER メッセージが来る度に、それを何倍にも掛け算した回数だけ呼び
　出される事が判明。例えば、秒間 N 回のタイマーを仕掛けると、OnCmdMsg が、
　 10*N 回呼び出されるような感じです。タイマーメッセージがくる度に、
　メニューなどを更新するためのメッセージが来ているような気がします。
　多分、本家 Windows では、タイマーメッセージが来ても、そのような事には
　ならないんじゃないかと思います。通常、OnCmdMsg は頻度が低いことが
省7

438(1): 2018/02/20(火)18:56 ID:nCkYsCc8(4/4) AAS
>>436
そうしたいんですが、何かと大変なんです。

1. メールアドレスの登録するのが、Linuxからだと大変。
2. git の仕様が良く分からない。
3. 回線が遅いので、Project を Fork して、git が Tree 全体を
　アップロードしようとしてしまったりなんかすると大変な事になる。
4. だから、一部のファイルだけを UL したいが、コミュニケーションの
　問題から事情を伝えて、そこまで行くかどうか分からない。
5. だから、独自にオーバーライドしようとしたのが、先日からここでも
　書いていたことです。loader を修正して、かつ、環境変数を変えて
省1

439(1): 2018/02/20(火)18:59 ID:TT83z4l8(1) AAS
>>438
githubからでもプルリクエスト受け付けてるよ

440: 2018/02/20(火)19:09 ID:LN/W3cN7(1) AAS
先に外部ﾘﾝｸ:bugs.winehq.orgに書いた方がいい
報告してあるとパッチ送る時説明が楽になるから

441: 2018/02/20(火)19:12 ID:hMkWg0ue(1) AAS
描画が早くなるならありがたい
素のWindowsより異様に遅いゲームとかあるし

442: 396 2018/02/20(火)20:06 ID:ErFPSqeX(1) AAS
結論だけ書いておくと、surfaceが非NULLの時の LineTo の実体は、
windrv_LineToで、surface を lock する以外は、dibdrv_LineTo と同じ。
dibdrv_LineToは、bits なるpixel配列に 32BITの色値を書き込む。
実際は汎用性のため、必ずandしてからxorする。SOLIDモードの場合、and値は0。
xor値は、00RRGGBB で、最上位バイトは0。
実際への画面の反映は、定期的に「xxx->flush」なる関数ポインタを介して、
x11drv_surface_flush() を呼び出す事で行う。その中で、議題になっている
update_surface_region() も呼ばれる。最後に bits の内容を実画面に反映させる
ため、XShmPutImage()または、XPutImage(), XFlush()を行う。

surface->image の pixel バッファは、bits[] 配列と共通らしい。
省2

443(1): 396 2018/02/21(水)16:48 ID:SJPTXnf1(1/13) AAS
update_surface_region() が遅いんだと思って、
XShape の作成を、XShapeCombineRectangles() を使う方式から、
XCreateBitmapFromData() と XShapeCombineMask()
を使う方式へと変えた。

すると、1146 x 745 のサイズの Window で、

1. 自前のコードによる 1bit の mask bitmap 作成にかかる時間 :
796 (us)

2. XCreateBitmapFromData() と XShapeCombineMask() にかかる時間 :
38 (us)

3. XShmPutImage() と XFlush() ; x11drv_surface_flush()内の両方にかかる時間 :
省10

444: 2018/02/21(水)17:03 ID:SJPTXnf1(2/13) AAS
XSync() を追加しても、XShmPutImage() を XPutImage() に修正しても、
何をやっても見た目だけが更新されない。

445(1): 2018/02/21(水)17:09 ID:iuEniYB2(1/5) AAS
>>443

> update_surface_region() が遅いんだと思って、
> XShape の作成を、XShapeCombineRectangles() を使う方式から、
> XCreateBitmapFromData() と XShapeCombineMask()
> を使う方式へと変えた。

こうするとなんで速くなるの？

446: 396 2018/02/21(水)17:35 ID:SJPTXnf1(3/13) AAS
>>445
それは、
>>427-428
の部分と深く関係しています。

447(1): 2018/02/21(水)17:39 ID:SJPTXnf1(4/13) AAS
X の同期の問題ではなく、MDI Child Wnd の TITLE BAR をドラッグするとき、
なぜか、数秒経ってから、x11drv_surface_flush() がまとめて何十回も呼び出されている
可能性があるかも・・・。

デバッグ表示をリアルタイムで見ていると、見た目が変化する直前までデバッグ表示が
全く出ず、見た目が変化する直前に、どどっと、数十回分の x11drv_surface_flush()
がまとめて出てくる、という現象が起きている。

448(1): 2018/02/21(水)17:56 ID:iuEniYB2(2/5) AAS
>>447
flushしてないだけではなく？

449(2): 396 2018/02/21(水)17:57 ID:SJPTXnf1(5/13) AAS
AA省

450(1): 396 2018/02/21(水)17:58 ID:SJPTXnf1(6/13) AAS
AA省

451: 396 2018/02/21(水)18:24 ID:SJPTXnf1(7/13) AAS
>>448
PeekMessage()を回しているだけの時で、メッセージがキューに残り続けている場合、
メッセージを 200回 (100回？) PeekMessage するまでは、flush_window_surfaces()
されないコードになっている気がしませんか・・・。

452: 2018/02/21(水)18:32 ID:SJPTXnf1(8/13) AAS
GetMessage() の方もほぼ同じような感じかも。。

とにかく、flush_window_surfaces() がとてつもなく長い間、呼ばれないことが
あるコードになっている様に見えて、実際、実験してもそう思える。

上下前次 1-新書関写板覧索設栞歴

あと 550 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.038s