[過去ﾛｸﾞ] Win32API質問箱 Build125 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
614(1): 2019/11/10(日)09:22 ID:nWjdF62e(2/2) AAS
>>613
GetPixelの話だよ？
615(2): 2019/11/10(日)10:13 ID:2HW6YGp5(1/2) AAS
それはAeroのせいかも知れない。
色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやって
いかないので、Windowが重なっている場合、その内の一つでも色が変化した場合、
その場所に重なっている全ての Window の色が分からないと、画面に表示される
色が計算できない。Windowsは、昔はメモリが少なかったので、伝統的には、
各Windowが仮想VRAMを持たない設計になっていた。それと絡んで、Windowの
ピクセルの色を取得するには、そのWindowにWM_PAINTメッセージを送って、
アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
再描画をさせるのが伝統的やり方。
このやり方に従っているなら、ディスプレイ上の最終的な色を取得したい場合、
省2
616: 2019/11/10(日)10:14 ID:2HW6YGp5(2/2) AAS
>>615
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないので、
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないといけないので、
617: 2019/11/10(日)10:48 ID:IRh+3wYd(2/2) AAS
>>614
ああすまん、それはVistaから導入されたDesktop Window Managerのせいやね
Windows 7から改良されたからマシになってるはず
618(1): 2019/11/10(日)11:26 ID:GjrjejsC(1/3) AAS
aeroで半透明になるから描画に時間かかる←わかる
だからgetpixelに時間かかる←う〜ん
呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
619: 2019/11/10(日)11:30 ID:42Oft6n8(1) AAS
getdc(0)だと全部の合成してからビデオメモリからとってくるから遅い
個別ウィンドウ指定だとウィンドウ下のとかからも取れる上に早い
個別の描画内容は多分システムメモリ上にある
大体そんなような動作っぽい
getpixel使わないからbitbltの挙動だけど多分おんなじじゃないかな
620: 2019/11/10(日)12:37 ID:R9o6dqtJ(2/2) AAS
> 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
1x1のビットマップに転送して取得しているのでxpでも遅かった
621: 2019/11/10(日)13:55 ID:fP398yW4(1/3) AAS
>>615
> そのWindowにWM_PAINTメッセージを送って、
> アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
> 再描画をさせるのが伝統的やり方。
> このやり方に従っているなら
もうやってないというか「重なり」なんて概念がないよ。
動画再生して、他のウインドウの後ろに隠して、
その状態でタスクバーにマウス乗せてみ
画面に表示されてなくても、ウインドウの中身は更新されてるからさ。
最小化したときはアプリ側で描画止めてるソフトが多いけど
省3
622: 2019/11/10(日)13:57 ID:fP398yW4(2/3) AAS
>>618
× aeroで半透明になるから描画に時間かかる←わかる
○ 半透明処理はCPUで行っていて時間がかかる処理だったがああ
GPU処理をするようになって軽くなったから、Aeroで半透明が採用された
623: 2019/11/10(日)14:11 ID:hRll0rFL(1) AAS
>>606
GetDC GetPixel で取れない場合
外部ﾘﾝｸ:maverickproj.web.あれ.com/d3d11_04.html
外部ﾘﾝｸ:ka-ka-xyz.はて？.com/entry/20101209/1291890231
外部ﾘﾝｸ[html]:codeday.me
624: 2019/11/10(日)14:11 ID:O4L9SaaX(1) AAS
GPUを使うようになった時点で、GetPixelのような処理はGPU側に問い合わせを送って
その結果を返してもらうという形になったから、遅くなるというのはあり得る話。
625: 2019/11/10(日)14:17 ID:fP398yW4(3/3) AAS
昔はVRAMにあったものがGPUのメモリにあるわけだからね。
通常の描画処理は、CPUからは命令だけ投げてあとはGPUが処理するので
GPU内で完結するから速いんだよ。でもデータを取ってきたりするのは負荷が高い。
だからピクセル単位でとってくるよりも、一定の範囲をごっそり取るほうが
GPUに出す命令は減るから結果として速くなる。
626: 2019/11/10(日)15:48 ID:GjrjejsC(2/3) AAS
でもaero切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない
627: 2019/11/10(日)15:51 ID:u8+xJCBj(1) AAS
同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ
628: 2019/11/10(日)16:09 ID:GjrjejsC(3/3) AAS
もう滅茶苦茶だなｗ
そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ
で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ
629: 2019/11/10(日)16:51 ID:invbJGJm(1) AAS
Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど
630(3): 2019/11/12(火)19:29 ID:fqP05o8Z(1) AAS
HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。
631: 2019/11/12(火)19:33 ID:R9AMJEW8(1) AAS
>>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。
632: 2019/11/12(火)20:44 ID:mKGma296(1) AAS
>>630
SetWorldTransform
633: 2019/11/13(水)10:09 ID:OceCV+VL(1) AAS
DirectX使えば自由
上下前次1-新書関写板覧索設栞歴
あと 369 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.041s