[過去ﾛｸﾞ] 今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
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
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 の場合だけは
遅く動作するのでしょうか？？？
424: 396 2018/02/18(日)14:19 ID:HH6qVqdM(7/9) AAS
>>418 さんの指摘は凄く役立ちました。有難うございます。
ただし、こっちの調査不足のせいが大きいのでしょうが、以下の部分は、今回の
結果とは違っていたようです：
>415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
>矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。
「X側の描画性能の低下」が原因ではなく、「ピクセル値を比較する処理」自体が、
実は「静止状態」でも、常時、大幅に増加していた、ということです。
何の変化がないときにでも、百万ピクセルを比較し、ランレングスを導き出す処理を、
原則的には秒間20回もやっています。
また、図形が複雑だと、システムコールを呼び出す回数がランレングスの変化の回数倍
省7
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s