Win32API質問箱 Build125

1 名前：デフォルトの名無しさん [2019/02/27(水) 15:09:08.64 ID:6ExXwgQU.net] Win32APIについての質問はこちらへどうぞ。 ■注意 ・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。 ・日本語版MSDN Online Libraryは不完全です。 　英語版( msdn.microsoft.com/en-us/library/ )の利用推奨。 ・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。 ・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで ■過去スレ Win32API質問箱 Build124 mevius.5ch.net/test/read.cgi/tech/1510395780/ Win32API質問箱 Build123 mevius.2ch.net/test/read.cgi/tech/1475897582/ Win32API質問箱 Build122 echo.2ch.net/test/read.cgi/tech/1451988219/ Win32API質問箱 Build121 echo.2ch.net/test/read.cgi/tech/1438695290/ Win32API質問箱 Build120 echo.2ch.net/test/read.cgi/tech/1428570962/ ■関連スレ Visual Studio 2019 mevius.5ch.net/test/read.cgi/tech/1548765663/ Visual Studio 2017 Part6 mevius.5ch.net/test/read.cgi/tech/1528645068/ 【C++】 DirectX初心者質問ｽﾚ Part41 【C】 mevius.5ch.net/test/read.cgi/tech/1521786252/ 532 名前：デフォルトの名無しさん [2019/11/05(火) 11:28:00.41 ID:f5fZl2jz.net] > 昔は DWORD (Double WORD) と定義されていましたが LPARAMは 16bit,32bit共に LONG (符号付整数) 533 名前：デフォルトの名無しさん mailto:sage [2019/11/05(火) 11:48:37.07 ID:McETm4vA.net] >>519 64bitプログラミングであっても使用するAPIは実体としてはWin32APIだぞ Win64APIなんて実体はなく、論理的に実装区分として呼び分ける程度 つまりスレチでも何でもない 534 名前：デフォルトの名無しさん mailto:sage [2019/11/05(火) 19:37:14.92 ID:wVD+ILW8.net] double wordが32bitだなんて本来word幅が16bitという前提の話でインテルなら80286までのはずが386でパスされathlon64で再びパスされるという異常事態が今も続いているわけなんだが 535 名前：デフォルトの名無しさん mailto:sage [2019/11/05(火) 20:20:06.81 ID:Rmlz0hln.net] >>524 16bit CPUや32bit CPUという言葉と ポインタ = アドレス幅が違うことは普通にあるってわかってる？ 8086は16bit CPUでレジスタ幅は16bitだがアドレス幅は20bit（最大1MB） 80286も16bit CPUだがアドレス幅は24bit（最大16MB） 80386は32bit CPUでレジスタ幅、アドレス幅ともに32bitで 分かりやすい時代がPentiumの第一世代（1995年ぐらい）ぐらいまで続いたが Pentium Proからは物理アドレス拡張が搭載され32bit CPUだが アドレスバスは36bit（最大64GB）になったんだが 536 名前：デフォルトの名無しさん mailto:sage [2019/11/05(火) 20:52:13.30 ID:mHpC8FDb.net] >>525 釈迦に説法ご苦労 537 名前：デフォルトの名無しさん mailto:sage [2019/11/05(火) 21:08:53.99 ID:Rmlz0hln.net] 釈迦は俺やしｗ 538 名前：デフォルトの名無しさん mailto:sage [2019/11/05(火) 21:43:32.83 ID:mHpC8FDb.net] 俺メインフレームでdiagnose命令とかいじくってて 別な案件でhdlでcpu書いたりしてるけど 539 名前：デフォルトの名無しさん mailto:sage [2019/11/06(水) 01:32:27 ID:k1IDaN6Q.net] メインフレームw 何歳になってもイキリ小僧してるんだな サルのパパとママはご存命かい？ 540 名前：デフォルトの名無しさん mailto:sage [2019/11/06(水) 02:20:55.89 ID:71FJFoA8.net] >>529 何イキっとんねん 541 名前：デフォルトの名無しさん mailto:sage [2019/11/06(水) 04:07:48 ID:Z1mcKm+J.net] イキなりえなり 542 名前：デフォルトの名無しさん mailto:sage [2019/11/06(水) 07:21:07 ID:cnDla3Ge.net] >>525 ソフト的なAPIの話に物理アドレス空間で語るバカ乙w 543 名前：デフォルトの名無しさん [2019/11/06(水) 12:01:28.81 ID:o3tEvZiY.net] 釈迦がどうかはともかく >>525 が全くトンチンカンなレスであることは事実 いつものあいつだろ 544 名前：デフォルトの名無しさん mailto:sage [2019/11/06(水) 15:05:39.69 ID:Z1mcKm+J.net] >>532 APIの話だというのなら、OSが16bitだろうが32bitだろうが APIの仕様が代わるわけないんやで 異常事態でもなんでもなく、それが高い互換性の理由だ 545 名前：蟻人間 mailto:sage [2019/11/06(水) 15:13:44.92 ID:Z1hQUtYe.net] 64ビット対応で Get/SetWindowLongよりもGet/SetWindowLongPtrを使え。とか、 DialogProcの戻り値をINT_PTRにしろ。 とかの若干の変更点があるようだ。 546 名前：デフォルトの名無しさん [2019/11/06(水) 15:19:20.45 ID:o3tEvZiY.net] HANDLEもこっそりtypedefに_PTR変えたんだっけ 547 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:18:36.16 ID:7K0XtVuo.net] ダイアログプロシージャの戻り値がめんどうなことになる x86じゃBOOLだけどx64だとINT_PTR でもVC6だとBOOLはintだという 548 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:32:58.79 ID:sEmiRyTj.net] 歴史的理由で仕方のない面もあるが、 単一のソースで16bitと32bit、32bitと64bitでコンパイルできるようにしてきたから 型の実態は結局なんなんだ？って悩むことになってる。 もうそろそろネイティブ型だけを使えるようになってほしいが そのために言語を変えるほうが楽だろうな 549 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:44:34.42 ID:ubAK6fog.net] intとlongのサイズ違うこともあるしな c#みたいにint32みたいなの最初から用意しとけよ 550 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:48:09.03 ID:cfOynPV2.net] stdint.h使おう 551 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:23:16 ID:+N3PsKU8.net] 前に聞いた話だと、大型機が64BIT化した後も、intは、32BITの事が多いらしい。 552 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:26:43 ID:4jX7Qkw7.net] いいかげんな知識で語りたがるやつ多すぎ 553 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:27:07 ID:+N3PsKU8.net] 32BIT時代は、整数サイズとポインタサイズが一致していて、サイズの選び方に 悩むことが無く便利だった。果たして、整数型を全部64BITにして良いものか どうか。原則的に速度は変わらないとしても使用メモリは増えてしまう。 恐らく、exeファイルのサイズも増加するだろう。 554 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:42:22 ID:sEmiRyTj.net] コンピュータが遅かった時代はCPUに最適なデータ型を 使うことが重要だったが、今は数値型しかなくて データサイズは自動的に決まりますとかばかりだもんな 555 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:44:07 ID:+N3PsKU8.net] 64BITポインタptrと配列添え字idxに対して、 ptr[idx] と書いた場合、idxが32BITと64BITだと実は、32BITの方が 1クロック増えてしまう可能性が高い。なぜなら、マシン語レベルでは、 上記の演算で、ptrは64BIT整数として扱われ、ptr[idx]は、 *(ptr+idx)として処理される。ところが、64BIT+64BITの整数演算は あるが、64BIT+32BITの整数演算は無い事が多い。なので、 idxが32BITだと、いったん、64BITにBIT幅を拡張する命令を1つ 挿入する必要がある。 だから、64BITポインタのアーキテクチャだと、idxも64BITにした方が 速度が上がる可能性が高い。 556 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:45:21 ID:+N3PsKU8.net] >>544 >今は数値型しかなくてデータサイズは自動的に決まりますとかばかりだもんな C++だと今でもデータサイズは明示します。 557 名前：デフォルトの名無しさん [2019/11/07(木) 02:54:21.19 ID:PsJP4fV8.net] size_t型が無難にして最強 558 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:00:35.26 ID:sEmiRyTj.net] >>546 他の言語の話や。今は速度よりも利便性のほうが重要や 559 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:18:33 ID:+N3PsKU8.net] >>548 例えば、JavaScriptだと、数値型のデータサイズが自動的に決められている わけではなく、常に double 型(64BIT 浮動小数点型)なのですが、 整数は32BIT整数型までだと double型に精度を落とすことなく完全に 収まるので、何も考えずに正しく扱えるだけです。 JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。 560 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:23:20 ID:+N3PsKU8.net] >>549 また、JavaScriptは、シンプルな使い方では、原則、整数型がなく、 console.log(54 / 10); とすると、5.4と表示されます。これは、54や10が整数ではなく、 54.0 や 10.0 という double 型浮動小数点として扱われているためです。 これは、Sun/Oracle の Java とは全く結果が異なります。後者では、 54/10は、「整数除算」なので、結果は整数の「5」となります。 561 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:38:26 ID:sEmiRyTj.net] > JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。 64bitも使うのかって話なんだけどな？ 52bitで十分だろう？ https://sbfl.net/blog/2018/06/18/javascript-bigint/ > JavaScriptのNumber（数値型）は倍精度浮動小数点数となります。 > つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、 > Numberを用いて正確に表せる最大の整数は、53bitで表せる数から > 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。 562 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:39:52.10 ID:sEmiRyTj.net] なんだ。JavaScriptにBigIntあるじゃん Numberで表せる最大の整数値は十分な値にも思えますが、 分野によってはこれでも足りなくなることがあります。そこで導入されたのがBigIntです。 BigIntは、任意精度の整数を表す新しいプリミティブ型です。 任意精度の整数値については、基本的にCPUに搭載されている計算機は対応していないので、計算はソフトウェアによって行われます。 563 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:43:05 ID:sEmiRyTj.net] やっぱりどんなときでもプログラマがデータ型を 選んでくださいっていうのは時代遅れだと思わ 564 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:53:54.05 ID:+N3PsKU8.net] >>553 自動化することは可能ですが、現在の技術でそういうところまで自動化した 言語を使ってコンパイラ処理系を書くと、コンパイル速度が100倍遅くなる かも知れません。これはコンパイル意を作成した経験に基づく話です。 もの凄く厳しい世界が実はまだ沢山残っています。 565 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:55:32.96 ID:+N3PsKU8.net] >>554 誤：かも知れません。これはコンパイル意を作成した経験に基づく話です。 正：かも知れません。これはコンパイラを作成した経験に基づく話です。 566 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:58:19 ID:sEmiRyTj.net] 100倍遅くなるなら100倍高速なコンピュータを使えばいいだけ 567 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:58:57 ID:sEmiRyTj.net] 今より100倍遅かった時代もあるのに 何を言ってるんだろうか？ それこそ時代遅れの感覚 568 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:59:39 ID:sEmiRyTj.net] あと、「かも知れません。」とかいう推測はどうでもいいから コンパイラを作り上げた俺が言うのだから 説得力は高いだろうし 569 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:00:34.74 ID:+N3PsKU8.net] >>555 GPGPUなどの世界でも、乗算速度がfloatとdoubleでは、4倍以上も違うような 例も多いのです。また、doubleをサポートして無いGPGPUの場合、doubleの乗算を floatや整数型などにバラして処理するので数10倍かかります。 なので、慎重になる必要があります。 CPUの場合でもintとdoubleで速度がかなり違うことが多いです。 570 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:02:01.90 ID:sEmiRyTj.net] あと極まれにスピードが重要な部分があるから 全部スピード重要視しろとかいうアホな感覚なｗ あれはやめてほしい。 極稀に重要なら、極稀に使うものを作ればいいだけ よく使うものを短くする。（仕事の）圧縮の鉄則 571 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:02:17.73 ID:+N3PsKU8.net] >>558 あなたより私の方が良いコンパイラを作っている可能性も有りますよね。 572 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:05:54.80 ID:+N3PsKU8.net] >>560 自動化の道は検討の価値はあるでしょう。 しかし、int32型とint10000000型を自動的に取捨選択できるほど、 コンパイラが賢くなるのは恐らく遠い未来です。 どこかで機能制限や精度を人間が指示する必要があると考えられます。 573 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:07:52.13 ID:sEmiRyTj.net] >>561 そういう俺のほうが優れてるとか言う主張をしたいなら、 個人を特定できるような情報をだせ 574 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:08:39 ID:sEmiRyTj.net] >>562 コンパイラが無理なら実行時にメモリ拡張すればいいだけ そういうことも思いつかないから、その程度止まりなんだよｗ 575 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:08:50 ID:+N3PsKU8.net] >>563 それはお互い様です。 576 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:11:41.18 ID:+N3PsKU8.net] >>564 それでは明らかに遅く、数値計算、コンパイラ、翻訳、AI、データ処理、 OSなどの作成には向いていない言語になるでしょう。 577 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:12:20.64 ID:sEmiRyTj.net] 大胆に変数はすべて128bitしかないという言語だって考えられる 最大 340282366920938463463374607431768211456 までしか扱えないが 578 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:13:03 ID:sEmiRyTj.net] >>566 そんな言語が今はたくさんあり実用化されています。 579 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:17:30.53 ID:+N3PsKU8.net] >>567 64BIT整数ですら効率を考えて使用を躊躇する世界に我々はまだいます。 あなたが普段使っているコンパイラも、非常に細かい高速化を施して あるので快適に使えているだけで、PythonやJavaScript、Rubyなどの 動的言語では達成できません。 例えば、JavaScriptの遅さは、全てdouble型にして、変数は、全てheapメモリ から確保することが主原因の一つです。それだけでC++の数十倍以上遅くなっています。 あなたの考えてことは、JavaScriptをさらに遅くするような結果となるでしょう。 580 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:18:51.44 ID:+N3PsKU8.net] >>568 有りますが、C/C++、Java、PythonやJavaScript、Ruby、Java、Kotlinなどの メジャー言語ではそのような方針はとっていません。 581 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:23:37 ID:+N3PsKU8.net] >>564 「その程度どまり」と言いますけど、あなたは私の作品を全く見てませんね。 全く発表してませんから。 582 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 05:42:32.39 ID:xrNXmkmc.net] スレ違いのバカ二人はどこかよそに行って気の済むまで殴り合ってきてくれ 583 名前：デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 06:22:21 ID:D8b5RtWG.net] > つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、 > Numberを用いて正確に表せる最大の整数は、53bitで表せる数から > 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。 ひどい説明だな どのくらいひどいかというと WM_SYSTEMMENU並み 584 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 11:03:05.72 ID:JQdG/Jj/.net] 公共の場で変数型のピロートークですか 585 名前：デフォルトの名無しさん [2019/11/07(木) 11:05:56.88 ID:dB1QBG ] [ここ壊れてます] 586 名前：Xo.net mailto: >>545 size_t 使え [] [ここ壊れてます] 587 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 11:27:25.53 ID:nSoHFrko.net] >>575 NULLは0だから〜 site_tはどうせintだから〜 こういう馬鹿なハケンが一人いると崩壊するよね 588 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 12:11:51.38 ID:sEmiRyTj.net] とか言うやつほどnullptrのことを知らなそうｗ 589 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 12:17:00.95 ID:9pMbL+ZJ.net] （´∀｀）＜ぬるぽ 590 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 17:55:20.14 ID:7K0XtVuo.net] #ifdef _WIN64 #define BOOLX64 INT_PTR #else #define BOOLX64 BOOL #endif BOOLX64 CALLBACK Dlg(HWND hw, UINT msg, WPARAM wp, LPARAM lp) こうやって回避してるわ 591 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 18:14:03.25 ID:2gAeIIzZ.net] Windowsのデータ型だけのヘッダファイルって無いかしら？ データ型はあちこちで使わざるを得ないから、あちこちでincludeしたいけど、 APIのヘッダファイルはincludeしたくない。 APIを直接使うのは面倒だから、全部ラップしてるんだよね。 だから他からは使えないようにしたい。 592 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 19:03:13.60 ID:+mjs9icr.net] データ型もラップしとけよ 593 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 19:07:36.74 ID:2gAeIIzZ.net] >>581 どうやってラップすればいいですかね？ 594 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 19:16:08.80 ID:2gAeIIzZ.net] なんとなくわかったからいいやｗ 595 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 21:31:30.10 ID:6aSe0RTj.net] 横にそれるが データ型もAPIの一部だと思ってるがあってるよな？ 596 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 21:47:07.60 ID:nSoHFrko.net] アプリケーション独自の型なんか知りませんがな 597 名前：デフォルトの名無しさん mailto:sage [2019/11/07(木) 23:33:07.15 ID:rEYaLqlI.net] 個人的には構造化したほうがやりいいかな 598 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 03:59:17.05 ID:ksOnEph7.net] お前らMFCでも使ってろ 599 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 04:54:11 ID:2aYByRbi.net] 普通のアプリならMFCが一番だと思うんだがなあ 変に角を丸くするとか透明にするとかされても使いにくいだけだろうに 600 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 05:57:08.22 ID:bt2cbsd4.net] むしろMFC = 角を丸くするとか透明だろ MFC以外でそんなの見たことないわｗ 601 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 07:30:44.18 ID:D1bzmSlR.net] あんまりMFC関係なくね？ WS_EX_LAYEREDもSetWindowRgnもAPIを陽に意識して使うわけで MFCはラッパーとしての薄さがありがたいだけやん 602 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 07:52:07.38 ID:tDaXxZK7.net] MFCはかゆいところに手が届かないからな 廃れたWTLがいい 603 名前：デフォルトの名無しさん [2019/11/08(金) 09:32:12.24 ID:MipGbP9q.net] >>591 WTLは廃れてないよ。今もちゃくちゃくと最新コードがコミットされ続けている。現時点で2019年11月3日(日)が最終更新。 https://git.code.sf.net/p/wtl/git 604 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 11:37:03.54 ID:bt2cbsd4.net] 廃れたかどうかは、使ってる人がいるかどうかであって 作っている人がいるかどうかではない 605 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 12:13:14.99 ID:xtk88Sle.net] 俺が使ってるから廃れてないぞ 606 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 12:17:45.01 ID:2aYByRbi.net] >>594 ちょと見せてみて？ 607 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 13:27:31.55 ID:D1bzmSlR.net] あんまり不人気だと 供給側も撤退を考える要素が色々出てくるだろ 608 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 13:56:39.50 ID:1R79qYgq.net] ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います 1803でも修正するくらいだしさ 609 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 21:00:43.55 ID:lpVjWTGo.net] TOPMOST ウィンドウがほかのウィンドウの背後に移動してしまう https://social.msdn.microsoft.com/Forums/ja-JP/17563f89-9838-4beb-925f-32f47d90c994/topmost 610 名前：デフォルトの名無しさん mailto:sage [2019/11/08(金) 21:14:49.46 ID:sQQR9KNr.net] TOPMOST同士があるからな 611 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 13:55:21.92 ID:hHKZwsDl.net] タスクマネージャもよく後ろに移動する時あるけど何なのあれ 612 名前：デフォルトの名無しさん [2019/11/09(土) 14:13:06.87 ID:BZG37V3w.net] API設計が糞だから 皆がみんなTOPを取りたがって 奪い合いになる 613 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 15:42:27.57 ID:01iIJK4d.net] タスクバーより手前にくる時もある 別件だが タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある 614 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 17:34:31.94 ID:GyhiHYRD.net] もう記憶の彼方ですがディスプレイメモリのアドレスって直で取れましたっけ？ 毎回メモリ確保してDIB作って画面のHDCからコピーしてっやらないと駄目すかね それなら諦めてGetPixel使いますが 615 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 17:44:43.05 ID:HanEs9+F.net] アドレスを直で、の正確な意味がわからんが基本あれGPUにあるからね Direc3Dテクスチャで良いならIDXGIOutputDuplicationから取れるけど 616 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 17:56:17.05 ID:HyuDdIlK.net] TOPMOSTなんて思い上がった言葉ですぐ気がつけよ スレッドの優先度でさえ最優先ではなくタイムクリティカルだろうが 617 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 18:03:02.50 ID:GyhiHYRD.net] >>604 こりゃ失礼、ありがとうございます なんか昔いじった気がしたんですが、あれはオフスクリーンバッファだったか…… PC98じゃあるまいし、言われて見りゃ無理くさいすね 画面上の変化を監視して作業自動化する様なのを頼まれたのですが、 監視するべきは数ピクセルなので、おとなしくGetDC(nullptr)からGetPixelします 618 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 21:35:29.14 ID:hHKZwsDl.net] GetPixelって内部でどうやってるのかな 毎回呼び出すと遅いんだよね 619 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 22:19:46.16 ID:HyuDdIlK.net] 故意に減速してるようだね ビットマップオブジェクトにキャッシュしといて そこから取ると普通の速度になる 620 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 22:41:44.97 ID:e6n/6jzv.net] gnsk 621 名前：デフォルトの名無しさん mailto:sage [2019/11/09(土) 23:25:01.42 ID:HanEs9+F.net] 仮にVRAMから1ピクセルだけ毎度読み戻してたらそらクソ重いやろとは思うが 今のDWMってGDI周りの扱いがどうなってんのかよくわかんねえからな 622 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 06:21:08.90 ID:nWjdF62e.net] XPでは爆速だったのがVistaから突然遅くなった 623 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 09:02:24.14 ID:R9o6dqtJ.net] TOPMOSTの競合の話ではない "ごく稀に TOPMOST ウィンドウが通常のウィンドウの背面に移動してしまう現象が発生するとお問い合わせいただいています。" "•Windows 8.1 以降、Windows 10 でも数十回に 1 回程度この現象が発生します。" 624 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 09:11:24.47 ID:IRh+3wYd.net] >>611 メモリー積め ってかPC買い替えろ 625 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 09:22:52.91 ID:nWjdF62e.net] >>613 GetPixelの話だよ？ 626 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 10:13:14.69 ID:2HW6YGp5.net] それはAeroのせいかも知れない。 色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやって いかないので、Windowが重なっている場合、その内の一つでも色が変化した場合、 その場所に重なっている全ての Window の色が分からないと、画面に表示される 色が計算できない。Windowsは、昔はメモリが少なかったので、伝統的には、 各Windowが仮想VRAMを持たない設計になっていた。それと絡んで、Windowの ピクセルの色を取得するには、そのWindowにWM_PAINTメッセージを送って、 アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の 再描画をさせるのが伝統的やり方。 このやり方に従っているなら、ディスプレイ上の最終的な色を取得したい場合、 例えたった1点の色であっても、非常に沢山のCPUパワーを必要としてしまう可能性が ある。仮想VRAMにキャッシュしておけば高速化できる可能性は高いが。 627 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 10:14:06.88 ID:2HW6YGp5.net] >>615 誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないので、 誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないといけないので、 628 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 10:48:16.19 ID:IRh+3wYd.net] >>614 ああすまん、それはVistaから導入されたDesktop Window Managerのせいやね Windows 7から改良されたからマシになってるはず 629 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 11:26:39.91 ID:GjrjejsC.net] aeroで半透明になるから描画に時間かかる←わかる だからgetpixelに時間かかる←う〜ん 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ 630 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 11:30:44.05 ID:42Oft6n8.net] getdc(0)だと全部の合成してからビデオメモリからとってくるから遅い 個別ウィンドウ指定だとウィンドウ下のとかからも取れる上に早い 個別の描画内容は多分システムメモリ上にある 大体そんなような動作っぽい getpixel使わないからbitbltの挙動だけど多分おんなじじゃないかな 631 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 12:37:49.81 ID:R9o6dqtJ.net] > 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ 1x1のビットマップに転送して取得しているのでxpでも遅かった 632 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 13:55:52.22 ID:fP398yW4.net] >>615 > そのWindowにWM_PAINTメッセージを送って、 > アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の > 再描画をさせるのが伝統的やり方。 > このやり方に従っているなら もうやってないというか「重なり」なんて概念がないよ。 動画再生して、他のウインドウの後ろに隠して、 その状態でタスクバーにマウス乗せてみ 画面に表示されてなくても、ウインドウの中身は更新されてるからさ。 最小化したときはアプリ側で描画止めてるソフトが多いけど それでも最小化した時点の縮小画面は見れるし Windows VistaのAeroから変わってるんだわ。 半透明処理もGPUにやらせてるからWindows 2000の頃と違い格段に軽くなってる。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef