[過去ﾛｸﾞ] 今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
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() を介して呼び出される。
flush_window_surfaces() の中に次のようなマクロ呼び出しがある :
LIST_FOR_EACH_ENTRY( surface, &window_surfaces, struct window_surface, entry )
surface->funcs->flush( surface );
ここで、
/* iterate through the list using a list entry */
#define LIST_FOR_EACH_ENTRY(elem, list, type, field) \
for ((elem) = LIST_ENTRY((list)->next, type, field); \
&(elem)->field != (list); \
(elem) = LIST_ENTRY((elem)->field.next, type, field))
であり、上記は、window_surfaces リストに登録されている全ての
window_surface *surface について、window_surface_funcs *funcs の
関数ポインタ flush の関数を呼び出すことになり、結局、
関数 x11drv_surface_flush() が呼び出されることになる。
関数 x11drv_surface_flush() の中に
if (surface->is_argb || surface->color_key != CLR_INVALID) update_surface_region( surface );
とある。update_surface_region() は、>>418 に書かれている関数。
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を作成
済みであること。
3. さらに、SetLayeredWindowAttribute() に LWA_COLORKEY を指定して「完全透明色」を
指定していること。
4. その Window の背景を「完全透明色」で消去していること。
5. その Window 内部に通常色で、LineTo() や TextOut() によって図形や文字を
描いた後であること。
です。
MDIを使っている事や、CMDIChildWnd 動かすかどうかは関係ない様です。
CMainFrame をドラッグした時には遅く感じないのは、その動作についてはシステムが CPU
の優先順位を上げているからではないかと思います。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s