今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Linux上でWindowsのアプリを動作させるソフトウェア
Wineに関する情報交換スレ。
前スレ
今夜も Wine で乾杯! - 20本目
https://mao.2ch.net/test/read.cgi/linux/1455088008/
Wine本家
http://www.winehq.org/
http://wiki.winehq.org/
動作報告Wikiや過去ログなど
http://www.2chlinux.org/index.php?FrontPage
ここにパッチをうｐするときはgzipやbzip2で圧縮した上で
base64などでエンコードしてください。おながいします。
動作報告は>>2のテンプレ使用を推奨。 >>427
>矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
>BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。
少なくともその方法だと、図形の複雑さによらずに安定して同じ処理時間で
済みますね。それと当然、BitBlt はハードウェアの補助が得られます。
あと、システムコールも全体で数回しか呼ばなて済みますし。 特定のアプリの場合にだけは、自作の user32.dll.so を読み込ませる事が出来ない。
WINEDLLPATH, WINEPATH を試してみたが、今のところ上手く行かない。 調べてみると、/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 */
const char *get_dlldir( const char **default_dlldir )
{
*default_dlldir = DLLDIR;
return dlldir;
}
となっているが、DLLDIR が全ての拡張子の全ファイルを全文検索しても
どこにも定義されておらず、参照されているのも唯一この関数だけだった。
これだと、WINEDLLPATH で「Override」できないのも当然だけど、
そもそも、DLLDIR がどこで定義されているのかが分からないので
誰かの教えをいただきたいです。 見つかりました。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`\"
というのが。単語検索していたのが鬼門でした。 loader.c の build_dll_path() の修正と、user32.dll.so の修正を、
自分のアプリだけに適用する事に成功しました。 surface が NULL ではない場合、xxx->pLineTo() は、X11DRV_LineTo()
ではなく、dibdrv_LineTo() が呼び出されるような・・・。 DirtyBit を使って、例の update_surface_region() は、
描画してないときには全く呼ばれないようにできたんですが、
まだかなり遅いです。何もしてないときにも CPU パワーがかなり消費されています。
その間、update_surface_region() が呼び出されていないことは、FIXME で
表示して確認が取れています。
なお、>>433は、windrv_LineTo() の方の間違いでした。windrv_LineTo() の場合、
簡単に surface にアクセスできるので、surface に bNeedToUpdate のような
フラグを追加して、それを 1 にして dirty bit にしています。
なぜ遅いままなのかは謎です。 2ch(5ch?)は人は多いけど基本的にユーザーレベルの人ばかりだから技術的な書き込みしても反応は鈍いね
Qiitaにでも書いてみたらどう？ 遅い原因の1つは、Onldle の中にあることが分かりました。
1. 必要があって、外部ツールによるファイルの更新チェックをしていたところ、
それがとんでもなく重い事が判明。
2. SetTimer で CMainFrame にタイマーをしかけていると、CMainFrame::OnCmdMsg()
が、WM_TIMER メッセージが来る度に、それを何倍にも掛け算した回数だけ呼び
出される事が判明。例えば、秒間 N 回のタイマーを仕掛けると、OnCmdMsg が、
10*N 回 呼び出されるような感じです。タイマーメッセージがくる度に、
メニューなどを更新するためのメッセージが来ているような気がします。
多分、本家 Windows では、タイマーメッセージが来ても、そのような事には
ならないんじゃないかと思います。 通常、OnCmdMsg は頻度が低いことが
前提になっているので、その中で多少重い処理をしていると、とんでもなく
重たくなる。
なお、透明色を使っている場合、update_surface_region の中の処理の軽重に
よって、描画速度が大幅に変わることも確認しました。
ランレングスを数えてリージョンを add_row している箇所を、単純に何も
数えずに行全体で、1個だけ add_row するように修正してみると、描画が
だいぶ速くなりました（透明にはなりませんが。）。 >>436
そうしたいんですが、何かと大変なんです。
1. メールアドレスの登録するのが、Linuxからだと大変。
2. git の仕様が良く分からない。
3. 回線が遅いので、Project を Fork して、git が Tree 全体を
アップロードしようとしてしまったりなんかすると大変な事になる。
4. だから、一部のファイルだけを UL したいが、コミュニケーションの
問題から事情を伝えて、そこまで行くかどうか分からない。
5. だから、独自にオーバーライドしようとしたのが、先日からここでも
書いていたことです。loader を修正して、かつ、環境変数を変えて
やれば、本家と統合しなくても、部分書き変えのような事が出来る。 >>438
githubからでもプルリクエスト受け付けてるよ 先にhttps://bugs.winehq.org/に書いた方がいい
報告してあるとパッチ送る時説明が楽になるから 描画が早くなるならありがたい
素のWindowsより異様に遅いゲームとかあるし 結論だけ書いておくと、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[] 配列と共通らしい。
つまり、Linux の描画関数は全く使わずに自前で画像をpixel配列に合成してから、
定期的に、XPutImage() などで実が面に描き込む、というようなことをやっているらしい。 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()内 の両方にかかる時間 :
94 (us)
4. MDI Child Wnd をドラッグするときに、x11drv_surface_flush() が
呼び出される時間間隔 :
3〜100 (ms) ---> 秒間 10回〜330回
5. 肉眼で描画が更新されるまでに x11drv_surface_flush() が呼び出される回数 :
数10回 以上あることが多い。
1.〜4. だけみると、高速に処理されている様に見えるけど、5. だけが理解できない。
カウンタを設けて数えてみると、実際に目では更新が起きてないのに、
ちゃんと、1〜3 の全ての関数が数十回も呼び出されている。
ちゃんと「XFlush()」されているのに、なぜだろう？？？？ XSync() を追加しても、XShmPutImage() を XPutImage() に修正しても、
何をやっても見た目だけが更新されない。 >>443
> update_surface_region() が遅いんだと思って、
> XShape の作成を、XShapeCombineRectangles() を使う方式から、
> XCreateBitmapFromData() と XShapeCombineMask()
> を使う方式へと変えた。
こうするとなんで速くなるの？ >>445
それは、
>>427-428
の部分と深く関係しています。 X の同期の問題ではなく、MDI Child Wnd の TITLE BAR をドラッグするとき、
なぜか、数秒経ってから、x11drv_surface_flush() がまとめて何十回も呼び出されている
可能性があるかも・・・。
デバッグ表示をリアルタイムで見ていると、見た目が変化する直前までデバッグ表示が
全く出ず、見た目が変化する直前に、どどっと、数十回分の x11drv_surface_flush()
がまとめて出てくる、という現象が起きている。 以下のコードが気になる。
message_count を減少させるのは唯一、wait_message() しか見つからなかった。
後は、check_for_driver_events() の中で単調増加してしまう。
メッセージがたまって初めて、flush_window_surfaces() が呼び出されるような
コードにも
/* check for driver events if we detect that the app is not properly consuming messages */
static inline void check_for_driver_events( UINT msg )
{
if (get_user_thread_info()->message_count > 200) {
flush_window_surfaces( FALSE );
USER_Driver->pMsgWaitForMultipleObjectsEx( 0, NULL, 0, QS_ALLINPUT, 0 );
}
else if (msg == WM_TIMER || msg == WM_SYSTIMER) {
/* driver events should have priority over timers, so make sure we'll check for them soon */
get_user_thread_info()->message_count += 100;
}
else get_user_thread_info()->message_count++;
}
static DWORD wait_message( DWORD count, const HANDLE *handles, DWORD timeout, DWORD mask, DWORD flags )
{
DWORD ret = USER_Driver->pMsgWaitForMultipleObjectsEx( count, handles, timeout, mask, flags );
if (ret == WAIT_TIMEOUT && !count && !timeout) NtYieldExecution();
if ((mask & QS_INPUT) == QS_INPUT) get_user_thread_info()->message_count = 0;
return ret;
} BOOL WINAPI DECLSPEC_HOTPATCH PeekMessageW( MSG *msg_out, HWND hwnd, UINT first, UINT last, UINT flags )
{
MSG msg;
USER_CheckNotLock();
check_for_driver_events( 0 );
if (!peek_message( &msg, hwnd, first, last, flags, 0 ))
{
DWORD ret;
flush_window_surfaces( TRUE );
ret = wow_handlers.wait_message( 0, NULL, 0, QS_ALLINPUT, 0 );
/* if we received driver events, check again for a pending message */
if (ret == WAIT_TIMEOUT || !peek_message( &msg, hwnd, first, last, flags, 0 )) return FALSE;
}
check_for_driver_events( msg.message );
/* copy back our internal safe copy of message data to msg_out.
* msg_out is a variable from the *program*, so it can't be used
* internally as it can get "corrupted" by our use of SendMessage()
* (back to the program) inside the message handling itself. */
if (!msg_out)
{
SetLastError( ERROR_NOACCESS );
return FALSE;
}
*msg_out = msg;
return TRUE;
} >>448
PeekMessage()を回しているだけの時で、メッセージがキューに残り続けている場合、
メッセージを 200回 (100回？) PeekMessage するまでは、flush_window_surfaces()
されないコードになっている気がしませんか・・・。 GetMessage() の方もほぼ同じような感じかも。。
とにかく、flush_window_surfaces() がとてつもなく長い間、呼ばれないことが
あるコードになっている様に見えて、実際、実験してもそう思える。 そうか、もともとは、dirty bit 方式じゃないから、flush_window_surfaces() を呼ぶと、
再計算する必要が無いのに必ず再計算されてしまうから、呼び出す頻度を下げるしか
高速化する方法が無いために、そんな風なコードになっているのかもしれない。 そして、flush_window_surfaces() のコードでは、最低でも 50 (ms) の時間が経っていない場合には
処理をスキップするコードになっている。とことん、flush() しないコードになってしまっている。
これらが原因か・・・。
void flush_window_surfaces( BOOL idle )
{
static DWORD last_idle;
DWORD now;
struct window_surface *surface;
EnterCriticalSection( &surfaces_section );
now = GetTickCount();
if (idle) last_idle = now;
/* if not idle, we only flush if there's evidence that the app never goes idle */
else if ((int)(now - last_idle) < 50) goto done;
LIST_FOR_EACH_ENTRY( surface, &window_surfaces, struct window_surface, entry )
surface->funcs->flush( surface );
done:
LeaveCriticalSection( &surfaces_section );
} 元々の Windows では、LineTo などを実行すると瞬間的に実画面に反映される。
だから、そもそも Flush せずに見えないままの描画が残っているなんて時間は
ほぼ 0。
そう考えると、。Wine のこの実装はおかしいな・・・。
1. そもそもメッセージループを回している時しか flush される可能性が全くない
実装になってしまっているらしい。
2. メッセージループを回していても、メッセージがキューに残っている時は、
100回程度メッセージを読まない限り、flush されない。
Windows を「エミュレート」するのであれば、例えば、描いてから 50(ms) 経てば、
必ず flush する、という実装でなくてはならないはず。
Linux では、タイマー処理が難しいのかな？？？ 1. Windows (もちろん、NT系) の場合は、メッセージ・ループ長く帰ってこないプログラムも
絶対ダメというわけではない。
2. そういうプログラムの場合、Wine 側は、描画を、一定時間間隔で、別スレッドの
タイマー割り込みの中などで flush するようにしないと、 正しく、Emulation 出来
ないはず。 割り込みなら、別スレッドを起こす必要が無かった。スマソ。
あと、誤字訂正：
誤： メッセージ・ループ長く帰ってこないプログラムも
正： メッセージ・ループに長く帰ってこないプログラムも うーん
これがボトルネックになっているようには見えない
申し訳ないんだけど描画が遅くなる条件をもう一度書いてもらっていいですか？ うーんと。それはまあちょっと置いておいて、、、。
MDI Child Wnd の TITLE BAR を Drag している最中、メッセージループは一つも
回ってないんじゃないかと思う。
だから、>>455 の「1.」に書いた「flushされる必要条件」が満たされてない。
そのため、surface の pixel配列の内容が実画面に反映されないのではなかろうか。 ドラッグ中にマウスを静止させてしばらく待っていると、 x11drv_surface_flush() と
flush_surface_region() の両方が呼び出された事が FIXME 出力で確認できた。
静止させずにマウスをドラッグし続けると、FIXME 出力が全くでない。
しかも、それを行った時間が長いと、マウスボタンを離した後も、非常に長い間
システム全体がハングアップした様な状態になる。そして、長い沈黙の後、FIXME出力が
出る。
この沈黙の時間は、それまでドラッグしていた時間に比例しているように思える。
なぜだろう？？？ これはどこかに「何かが溜まっている」時の現象の様に思える。
しかし、>>449 を見ると、message_cnt は、減らされるときは、一期に 0 になるのであって、
少しずつ減らされるわけではない。
謎だ・・・。 単にイベントを送信する側でバッファリングしてるんじゃないの？ まあ最初からマルチスレッド意識して書いた感じではないなと思うけど90年代から開発されてるわけだしそのへんはご愛嬌じゃない >>449-450 辺りのソースを見ていて、背理法で語ってみたい。
仮定1：「Drag 中でも、PeekMessage されている。」 と仮定する。
仮定2. 透明化した際に重くなるのは、flush_window_surfaces() と、
そこから呼び出される update_surface_region() のみだと仮定する。
補足： update_surface_region() は、透明化のための Shape の作成の処理が
されるので、重い。
flush_window_surfaces() は、update_surface_region() を呼び出す
以外にも、XPutImage() 系の処理が入るので、さらに重い。
仮定2については、透明化時に、それ以外に重い関数が出現する可能性を否定は
できない。なぜなら、surface の処理は、透明化しない時には行われないかも
知れないからである。その場合、LineTo の関数が切り替わる。
1. FIXME で見ている限り、ドラッグ中は、それらの関数は全く呼び出されない。
2. >>450 を見ると、PeekMessage した際に、キューにメッセージが残ってないなら、
flush_window_surfaces() が呼び出されるはず。
3. 「仮定2」 の関数は呼ばれてないのだから、キューのメッセージは、透明化され
てない場合と同程度に高速に処理されてもおかしくない。
4. もしそうであれば、キューのメッセージはあっという間に「空」になるはず。
5. 空になったとしたら、「2.」の通りに、flush_window_surfaces() が呼び出されるはず。
6. しかし、「1.」で述べたように、実験的には、flush_window_surfaces() は呼び出されてない。
7. 矛盾である。
8. 背理法により、これは、仮定の少なくとも一方が間違っている事を意味する。 あるいは、Peek されるだけで、一部のメッセージは取り残されるなら・・・。 Wine で、MDI Child Wnd の TITLE BAR をドラッグしたときの処理について。
DEFWND_DefWinProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
-->case WM_NCLBUTTONDOWN
-->NC_HandleNCLButtonDown()
-->case HTCAPTION
-->SendMessageW( hwnd, WM_SYSCOMMAND, SC_MOVE + HTCAPTION, lParam )
-->DEFWND_DefWinProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
-->case WM_SYSCOMMAND
-->NC_HandleSysCommand()
-->WINPOS_SysCommandSizeMove()
最後の関数は、タイトルバーをドラッグを開始直後に一回だけ呼び出される事
を確認した。その後のドラッグ中は呼び出されず、この関数の内部でドラッグ
の処理がされている可能性が高い。
この最後の関数の中に、次のような、メッセージ・ループがある：
if (!GetMessageW( &msg, 0, 0, 0 )) break;
if (CallMsgFilterW( &msg, MSGF_SIZE )) continue;
/* Exit on button-up, Return, or Esc */
if ((msg.message == WM_LBUTTONUP) ||
((msg.message == WM_KEYDOWN) &&
((msg.wParam == VK_RETURN) || (msg.wParam == VK_ESCAPE)))) break;
if ((msg.message != WM_KEYDOWN) && (msg.message != WM_MOUSEMOVE)) {
TranslateMessage( &msg );
DispatchMessageW( &msg );
continue; /* We are not interested in other messages */
} さらに次のような、枠だけを書くか、実際に動かしてしまうコードが続く :
if (!DragFullWindows)
draw_moving_frame( parent, hdc, &sizingRect, thickframe );
else {
RECT rect = sizingRect;
MapWindowPoints( 0, parent, (POINT *)&rect, 2 );
SetWindowPos( hwnd, 0, rect.left, rect.top,
rect.right - rect.left, rect.bottom - rect.top,
( hittest == HTCAPTION ) ? SWP_NOSIZE : 0 );
} あー。
FIXMEを消してしまっていただけだった・・・。
update_surface_region() や、flush_window_surfaces() は、
ドラッグ中でも、マウスを静止してしばらくすると呼ばれるようです。
マウスを動かしつづけていると呼ばれないらしい。 【やっと原因判明】
CMainFrame を WS_EX_LAYERED で透明化していて、今回の条件に当てはまる時に、
CMDIClientWnd のタイトルバー上でマウスの左ボタンを押し始め、そのまま
マウスをずっと動かし続けると、WINPOS_SysCommandSizeMove() の中の
if (!GetMessageW( &msg, 0, 0, 0 )) break;
の部分の GetMessageW() 関数の中で停止してしまう。詳細は、GetMessageW() の
中で、メッセージキューが空だった場合に呼び出されるところの、
wait_objects() ;dlls/user32/message.c
-->wow_handlers.wait_message()
-->wait_message() ;dll/user32/winproc.c
-->USER_Driver->pMsgWaitForMultipleObjectsEx()
-->X11DRV_MsgWaitForMultipleObjectsEx()
の最後の関数の中で停止してしまう。
正常なら、WM_NCMOUSEMOVE メッセージが到着することによって、関数から
戻って来るはずだと思われる。 >>468
2つ目の WaitForMultipleObjectsEx() の中で停止してしまっていることが判明。
本来、先頭に Msg が付く方の API は、メッセージと HANDLE の両方を同時に
監視するようなコードでなくてはならないハズなのに、そうなってないらしい。
process_events() が、MotionNotify の XEvent が来ていたら WM_MOUSEMOVE
メッセージをキューにポストするらしいが、最初に一度だけ調べて XEvent が
来ていない場合は、以後、全く XEvent を調査せずに他の HANDLE 群の変化だけ
を待機してしまうらしい。
DWORD CDECL X11DRV_MsgWaitForMultipleObjectsEx( DWORD count, const HANDLE *handles,
DWORD timeout, DWORD mask, DWORD flags )
{
DWORD ret;
struct x11drv_thread_data *data = TlsGetValue( thread_data_tls_index );
if (!data) {
if (!count && !timeout) return WAIT_TIMEOUT;
return WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL,
timeout, flags & MWMO_ALERTABLE );
}
if (data->current_event) mask = 0; /* don't process nested events */
if (process_events( data->display, filter_event, mask )) ret = count - 1;
else if (count || timeout) {
ret = WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL,
timeout, flags & MWMO_ALERTABLE );
if (ret == count - 1) process_events( data->display, filter_event, mask );
}
else ret = WAIT_TIMEOUT;
return ret;
} 【通常時、WM_MOUSEMOVE がキューへ追加される時の実行経路】
X11DRV_MsgWaitForMultipleObjectsEx()
--> process_events()
---> call_event_handler( Display *display, XEvent *event )
---> handlers[event->type]( hwnd, event );
event->type = MotionNotify (6)
---> X11DRV_MotionNotify( HWND hwnd, XEvent *xev )
XMotionEvent *event = &xev->xmotion;
INPUT input;
---> send_mouse_input( hwnd, event->window, event->state, &input );
---> __wine_send_input( HWND hwnd, const INPUT *input )
---> send_hardware_message( hwnd, input, 0 );
SERVER_START_REQ( send_hardware_message ) {
switch (input->type)
case INPUT_MOUSE:
}
---> wine_server_call( req );
---> DECL_HANDLER(send_hardware_message)
(send a hardware message to a thread queue)
---> queue_mouse_message( desktop, req->win, &req->input, req->flags, sender );
messages[MOUSEEVENTF_MOVE (1)] = WM_MOUSEMOVE
---> queue_hardware_message() : WM_MOUSEMOVE
list_add_tail( &input->msg_list, &msg->entry );
set_queue_bits( thread->queue, get_hardware_msg_bit(msg) );
--->
if (!always_queue || merge_message( input, msg )) free_message( msg );
else {
msg->unique_id = 0; /* will be set once we return it to the app */
list_add_tail( &input->msg_list, &msg->entry );
set_queue_bits( thread->queue, get_hardware_msg_bit(msg) );
} 【WM_NCMOUSEMOVE は WM_MOUSEMOVE から修正される】
PeekMessageW() または GetMessageW() の中で、hittest が HTCLIENT 以外
の場合は、WM_MOUSEMOVE が WM_NCMOUSEMOVE に修正される :
PeekMessageW() または、GetMessageW()
---> peek_message()
---> switch(info.type)
case MSG_HARDWARE :
---> process_hardware_message()
---> process_mouse_message() {
if (hittest != HTCLIENT) {
message += WM_NCMOUSEMOVE - WM_MOUSEMOVE;
wparam = hittest;
} 頭に Msg が付かない方の WaitForMultipleObjecstEx() も
挙動がおかしい。 timeout に 0 を指定しても、無限に
待機してしまうことがある。 Msg が付く方の WaitXxxx で、usleep() で、0.3秒ほど停止しながら、
Polling (Loop) するようにしてから、FIXMEでメッセージを観察してみた。
普段は、usleep() 命令は、呼び出してから 0.3 秒で戻ってくる。
ところが、先日からの遅くなる条件でドラッグし続けた場合、単純な usleep() の
1命令が、呼び出してから、永久に戻ってこなくなる。ドラッグをやめると、
人間が長く感じるほどの長い時間が経過してから戻ってくる。
これは、WINEの問題ではなく、Linux Kernel の問題だろうか？？？ やったことをもうちょっと詳しく書いておくと、
>>469 の X11DRV_MsgWaitForMultipleObjectsEx() の関数の2番目の
WaitForMultipleObjectsEx() の呼び出しの箇所を次の様に修正してみた。
(FIXME はもっと付けてあるが省略):
if ( timeout == INFINITE ) {
//*中略*
for ( ;; ) { // 苦肉の polling loop :
ret = WaitForMultipleObjectsEx( count, handles, bWaitAll,
0, // (ms) (指定しても上手く行かないので0にしてみた)
bAlertable );
if ( ret == WAIT_TIMEOUT ) {
if ( process_events( data->display, filter_event, mask ) ) {
ret = count;
break;
}
}
else {
break;
}
FIXME( "call usleep\n" ); //(1)
usleep(1000 * 300); //(2) 仕様上は、300(ms)後に戻る。
FIXME( "returned from usleep\n" ); //(3)
}
}
else {
ret = WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL,
timeout, flags & MWMO_ALERTABLE );
}
該当の条件の時にマウスを動かし続けると、(1)のメッセージが出た後、
(3)のメッセージが、事実上、無限に待っても出てこなくなった。ドラッグして
ないときには、usleep()の仕様通り、300(ms)後にメッセージが出てくる。 かなり色々やったつもりだけど、ちょっとこれ以上深入りは難しいので、もう諦めようかも。
以下の上京からするとLinuxカーネルの問題かも知れない：
1. タスクバーも操作不能になる。
2. 単純な usleep() も無限に帰ってこない。 Wineでは、昔の MSDN Library の CD もインストールは出来ただが見られなかった。
hh.exe が xxx.COL ファイルを開けないと言ってくる。
yyy.CHM ファイルは、開くことはできたが、右のペーンだけが見えて、左側の目次や
検索のぺーンには何も表示されない。
今回 WINEのソースを見て思うのは、意外とちゃんと書かれていないということ。
MsgWaitXxxx にも、戻り値が明らかに間違っている部分を発見した。
また、TRUE (1)を引数に渡す必要があるところで、1ではない非0 の値を渡している
箇所も見つかった。そのようなコードは後々問題を来すかも知れない。
それに、MsgWaitXxx もちゃんと書かれていない。同時に待機するのは、アプリ・プログラマ
がどんだけ頑張ってもかけないから API が用意されているのだが、そこに明らかな
ロジックの間違いがある。
有名なアプリだけはちゃんと動作するが、実は模倣の程度が意外と低いかも。
有名なアプリだけは動くように調整されている・・・。 usleep() の部分を setitimer(), pause() に変えてみたら、そこは指定した
時間でちゃんと帰ってくるようになった。でも、Linux全体が停止に近い状態に
なる症状は変わらない。端末内の FIXME の表示が途中の文字まで書かれた状態で
改行までいく前に長い間停止する現象が起きてしまっている。 X Window System は、Server と Client で通信を行っているから、Client側では処理が
一瞬で帰って来ているように見えても、Server側では処理に凄く時間がかかっている可能性
があるかもしれない。だから Client側で、関数の呼び出しの前後の時間を計測をしても
それは単にServer にコマンドを送る処理の時間を計測しているに過ぎないのかも
知れない。イメージのバイト数が多いいときには、通信時のデータ・コピーに時間がかかる
から多少時間がかかるかも知れないが、それはまだ表面上の時間に過ぎず、Server 側は
Shapeのくり抜き処理(?)や重ね合わせの処理に膨大な時間がかかっている可能性も否定できない。
だから、XCreateBitmapFromData(), XShapeCombineMask(), XPutImage() の前後の時間を
計測しているだけでは速く見えても、見えない場所でCPUパワーを全開にしてがんばっても
まだ処理を終えてないのかもしれない。
だから、Linux Kernel は、X Serverに CPU パワーを全開まで与えようとしている・・・。
Client側で計測した時間は見せかけの時間であって、処理全体の時間ではない・・・。
だから、タスクバーなども動かず、デバッグ表示の端末の文字も中途半端な場所でWAIT
状態になってしまう・・・。
これが真相だろうか？ そういえば、update_surface_region() が呼び出されたことを示すデバッグ文字列は、後からまとめて
ドドッと出てくる。それは、文字列が「出てない」間には関数が呼ばれてないことを意味する
訳ではなく、実は呼ばれてはいるが、文字列が flush されてないか、または、flush
されていても、端末に CPU リソースが割り当てられないから、文字表示だけが行われずに
文字列がバッファに溜まった状態になってしまっている・・・・。
こう考えれば辻褄が合うかも。 本家の Windowsでは、描画処理が重いときには、OnPaint や OnDraw の関数が終わるまで
の時間も長い。だから、メッセージがたくさんたまっているのに描画が追いついていない事は、
メッセージ・キューに残っているメッセージの個数が多い事で大体の判断が付く。だから、
InvalidateRect(NULL)をしておけば、描画が追いついてない場合は、メッセージループ
が WM_PAINTメッセージを送るタイミングを自動的に後回しにしてくれる。
ところが、X Window System の場合、実際の描画がまだ終わってない場合でも、
「描画関数」自体は一瞬にして戻ってきてしまうから、上記のアルゴリズムが「勘違い」を
起こしてしまうことがある・・・。
そらに悪い事に、WINEが、内部で Surface を持っているときには、LineTo 関数自体は高速に
処理を終えるのに、アプリが予想もしないタイミングで、時間の掛かる flush の処理が行われ
てしまう。
そうすると、OnPaint は高速に終わったと勘違いして、WM_PAINT メッセージが、マウス・メッセージに
完全に連動して大量に生成されてしまう。すると、Pending 状態の X Window の処理がどんどん
待ち行列に溜まっていってしまう。
ドラッグ中は、WM_PAINT が秒間20回も送られるのに、Server が実際の描画を終えるのは、
その何十倍も時間がかかってしまう。
こんな感じだろうか。 さらに、>>465-466, >>468 に書いた、WINPOS_SysCommandSizeMove() は、
CWinApp などとは別の、独自のメッセージループを持っている。
そこでは、さらに、WM_PAINT が不適切に大量に発生してしまっている
可能性がある。
だんだん分かってきたかも。 原因は推定できてきたけど、さて、どうやってこれを解決すればいいか・・・。 ライセンスの関係でややこしいことに成る可能性が存在するから
５chへソースコードは書かないで
ｇｉｔｈｕｂ使ったほうがいい 粒度の低いパッチをちょこちょこアップすると良いのでは。
論理値のあやまりを直すやつとか。 >>483
それでは、日本人の自分に取って手も足もでない状況になってしまうので、とても
困ります。 >>485
なぜ？
ココに書けば問題が生じる可能性もあるのに 協力しにくくしにくくなるように仕向けられて、どうしようもない状態になってる気もする。
make時の表示の無駄が多すぎて、特に警告が出ていても見逃しやすいし、HDDも膨大に
消費するし、ダウンロードやアップロードにも莫大な時間がかかるし。
なんだか、アメリカと北欧の社会的環境以外ではとっても負担が大きいかも、 >>488
ここにソースコードを書けば5chが権利を主張する恐れがある
あなたが書いたものであっても
それは問題でしょう？ MSのやり方に困った人が集まってくるのがLinux。
でも、Linuxのやり方にもまた困る。UbuntuのUpdateも自分には出来ない。
なぜなら、HDDのパーティションの容量が足りないのと、DLに時間がかかりすぎるからと、
クリーンインストールしなきゃならないから、せっかく入れた Wine や Wz, VC++ などの再
インストールに莫大な時間がかかってしまうのとで。それでやっとの思いでなんとか協力
したいと思っているのに、また、ライセンスがどうのこうのとか。
わけが分からない。LinuxやUbuntuのバグに悩まされて、しょっちゅう Logout と Login
を繰り返しながら、やっとの思いでやってます。 MacでWine使ってるけど似たようんだもんだわ。 OSSやLinuxの問題ではなくて
5chのライセンス扱いの問題 >>489
そんな心配はないはずです。
自分は権利を放棄するつもりでやってますし、法的には Wine の LGPL が優先されて、
5ch は権利は主張できないハズ。もし、権利を主張するなら、5ch自体が人が来なくなって、
閉鎖されるでしょう。 >>493
OSSのソースコードを5chに書き写したらライセンスが移るかというとそうではないと思うけど
問題にされる可能性が存在する
新規のソースコードだった場合など、5chが権利を主張してOSSで扱えない可能性が出てくる >>490
Linux板でそういうこと言っても住人を不快にさせるだけだよ
誰も頼んでないのに愚痴言われてもさ
ブログか何かに書けば？ とはいっても、勝手に転載するな、の主張は現在進行でバンバンやってますからねえ… >>496
他所が権利を主張するコードの利用をOSS側が許すかという問題にかかわってきて
それは5chとは別になるね 【ついに出来た】
x11drv_surface_flush() の中で、
update_surface_region( surface );
を実行後、
XPutImage(・・・);
XFlush( gdi_display );
XSync( gdi_display, TRUE );
XSynchronize( gdi_display, True );
で関数が終わっていたところに、試しに
usleep( 1000 * 150 ); // 0.15(秒) の待機
を追加して見たところ、「改善（感覚的な速度アップ）」が見られました。
ちゃんと、ドラッグした時に「XOR反転枠」がマウスの動きに付いてきます。
今までは、「枠」が現れすらしなかったのに。試しに WAIT 値を「小さく」して、
usleep( 1000 * 100 );
とするとダメなままでした。WAIT 値が大きいほど、感覚的に速度がアップ
したような感じになります（一種の逆転現象）。
これは、X Window の Server の処理が終わってないのに、終わったと勘違いして
次々に新しいコマンドを X Server に送ってしまっていたことで、今回の不具合
が起きていたことを裏付ける物です。Linux が CPU パワーを X Server にばかり
与えてしまい、アプリ側のコードは停止する一方て、実際の画面には何の描画も
行われなくなり、タスクバーすら全く機能しなくなる。その結果、システムが
ハングアップしたようになる。 日本語でパッチの記述を書いてくれれば、英訳してくれる奴がスレにいると思うな。
最悪ぐぐる翻訳でも。
あとは日本人でwineにコミットしてる人を探してパッチを仲介してもらうとか… だいぶ前のレスだけれど、 >>439 は信じるなよ。
Wineに修正を送る方法はgit format-patchで整形したパッチを
wine-devel@winehq .orgにメールする方法だからな。(前近代的に感じるかもしれないけれど)
他にも要件がいろいろあるから、 ttps://wiki.winehq.org/Submitting_Patches を一読した方がいいと思う。 >>500
WINE 本家に正式採用されなくてもいいなら、github にプルリクエストを送る、なんて
事は可能なんでしょうか。
ライセンス上は、修正した箇所のソースの断片でも、どこでもいいからネット上のどこかに
アップロードしておけば良いんだと思うんですが。
ネットの回線が遅いから、自分が全く修正してない部分まで全部アップロードというのは
かなり困ります。 要は、著作権が発生するようなソースを書かなければいいんですね。
WINE で、WS_EX_LAYERED の場合に、現状の様に XShape を使わずに、
XCreateWindow の depth に 32 を指定して、ARGB カラーを使うようにして
透明化を実験して見たところ、高速になったようです。
まだ、中途半端ですが。 透明化、完全に上手く行きました。速度は劇的に向上。
システムの(事実上の)ハングアップも全く起きません。
現状で Windows との非互換な部分は、透明部分をクリックしても、下にある Window
にマウスメッセージが送られない、という一点だけです。 >>502
>要は、著作権が発生するようなソースを書かなければいいんですね。
そうそう
wine本家にマージさせるためにどこかにあげてというのでなく
自分のwebsiteでもgithubでもgooglecodeでも、問題がなさそうな場所へ >>506
Qiita にソースをULするのは、著作権的に問題ありそうですか？ Linux の X Window の XShape と、 Win32 の WS_EX_LAYERED は相性が悪いために
単に Win32 を Emulateしようとすると、多分、どうやっても遅くなってしまうと思うんです。
だから、Wine 専用に Windows には無いフラグや関数を定義して、ある新定義の
独自APIを呼んだタイミングでだけ、XShapeを呼び出す仕様にすればいいと思うん
です。それを呼び出さなくても、中の図形や透明部分は自由に変えられると。
で、メッセージが下(Desktopなど)まで届く部分を指定したい場合(外形を変えた
い場合等）だけは、その関数を呼ぶと。例えば、透明を使った一般のアプリでも、
輪郭は楕円にしておいて、中の絵だけを高速に変えたいような需要はあると思う
んです。それは、今の Wineでは出来ません。でも、今述べた方法なら可能になり
ます。
技術的には自分だけでも可能です。でも、この仕組みを本家Wineの人が納得して
くれるか分かりません。
なお、自分のアプリだと、「GroundWnd」なる「受け皿」を作ってそこでメッセー
ジを「せき止めて」下には透明部分であっても、敢えてメッセージが届かないよ
うにしているので、見た目だけ透明に出来れば十分なのですが。
でも、本家に統合してもらわないと、Wineのバージョンアップの度に、こっちで
その独自部分の追加作業が必要になったりして大変なんです。
なんとか話を付けることは出来ないものでしょうか？？？ >>510
早速、ここでの話を受けて、 Qiita に書いてみてます。 >>511
問題のアプリのサンプル(ソースコード込み)と修正した一連のコードをパッチにして
https://forum.winehq.org/
に送ってみたら？ >>513
>>511のような内容を英語で正確にやりとりするのに、とても精神的負担を感じます。
ちゃんと理解してもらえなくて、徒労に割りそうな予感も。 新定義の独自APIとか言い出したら正確に伝わっても賛同されるか疑問だ 結論的には、Wineを改造しても Windows API の仕様を変える訳ではありませんので、
もし、Wineの一部であっても、Windows API だけを使った dll の部分は、Wineの
バージョンが変わっても、原則的には自由に入れ替え可能な可能性があるのです。
kernel32.dll, gdi32.dll, user32.dll, ntdll.dll の4つの dll 以外のdllは、
WINEの内部がどのように実装されているかには依存していない可能性があると
いうことです。もしそうであれば、Wine のソースを改造してもこれらのdll.so以外は、
本家Wineが今後発表する新バージョンのものを、改造 Wine のバイナリファイル群に
後から上書きしても、互換性が保たれ続けるんじゃないかな、と思いました。つまり、
以下の 4つの dll.so だけを配布すれば、かなり長い間、独自の Wine として動作
できる可能性があるのではないかと。loader.c を修正した libswine.so.1.0 を配布
すれば、dll.so の検索パスも上手く「オーバーライド」できますので、以下のたかだか
18MB程度のファイル群を配布しさえすれば、標準の Wine を壊さないまま、独自の Wine を
特定のアプリにだけ適用し、両バージョンの Wine を共存できるのではないかと思えて
きたんです。
./libs/wine/libwine.so.1.0 1,933,464 # WINEDLLPATH 修正のため
./kernel32/kernel32.dll.so 5,526,999
./gdi32/gdi32.dll.so 2,655,524
./user32/user32.dll.so 4,267,471
./ntdll/ntdll.dll.so 3,256,245 >>516
その際、「wine server」の「server request」の仕様を変更さえしなければ、
標準の Wine を使ったアプリと、まさに同時実行も可能ではないかと。
実際、自分が実験する限り、標準の Wine を使った VC++ と Wz が、
特に問題なく独自 Wine の自前アプリと同時実行で来ているように見えますので。
なんというか、例えば、Wineの実装の構造体にメンバ変数を独自に追加した場合、
それが直接見えているソースは、同一の構造体の他のメンバの相対アドレス、構造体の
サイズが変わるために再コンパイルが必要です。しかし、それを直接見ているのは、
上の 4つの dllのdll.soファイルだけではないかと。そして、その他のdllは、その
構造体を直接見てないのではないかと。それで、カプセルの様にブラックボックスの
中に改造が閉じ込められてしまって、再コンパイルを全くしなくても外の dll 達に
は、その改造が破壊的な影響を与えずに、機能としての変化だけが伝達されるのでは
ないかと。 「dll.so」ではなく「drv.so」ですが、
/wine/dlls/winex11.drv/winex11.drv.so 1,797,340
も配布が必要ですので、合計20MB程度。圧縮すれば 10MB程度のはず。
だから、アプリ本体のバイナリと同時に 10MBを配布すれば独自修正 Wineが
配布できるかと。 >>515
やはり、そう思われますか。
一部の透明アプリに取っては、改造Wineの方がWindowsとの互換性がかなり上がりますが、
他の透明アプリに取っては下がる、見たいな状態になるので、意見が分かれるかな、と思って
たんです。でも、恩恵を受けるアプリもあります。 派生版みたいなのが乱立しそうで恐い
まあ、現状も最新版が必ずしも良いとは言えないから複数バージョンを使い分けるなんてことはやられているが これは大変更過ぎて厳しいだろ
フォークして勝手にやってと言われる可能性大 取り敢えず改変した物もしくはそれが置いてあるURLを本家に晒して反応を様子見かね MSDN Library の CD-ROM 版を、Wineにインストール出来ました。
https://qiita.com/Yutaka_Aoki/items/a83371ebf5c1e967a6f6
なお、確か、MSDN Library 2008 の ISO イメージは、無料で DL 出来たと思います。 wine下で動くspider.exeがやたらと速いんだが
delayが効いてないだけな気がしなくもない Ctrl+Insertでコピーできるようにしたいんだけど
何か方法ある？ そんなショートカットあったなあ
最近使ってなかったから忘れてた 155 名前：login:Penguin [sage]： 2018/03/01(木) 23:01:33.07 ID:fYfWMlBV
Ctrl+Insertでコピーしたいんだけどショートカット設定する方法ありますか？ ■ このスレッドは過去ログ倉庫に格納されています
