- 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/
- 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の頃と違い格段に軽くなってる。
- 633 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 13:57:05.17 ID:fP398yW4.net]
- >>618
× aeroで半透明になるから描画に時間かかる←わかる
○ 半透明処理はCPUで行っていて時間がかかる処理だったがああ
GPU処理をするようになって軽くなったから、Aeroで半透明が採用された
- 634 名前：デフォルトの名無しさん [2019/11/10(日) 14:11:16.15 ID:hRll0rFL.net]
- >>606
GetDC GetPixel で取れない場合
maverickproj.web.あれ.com/d3d11_04.html
ka-ka-xyz.はて？.com/entry/20101209/1291890231
https://codeday.me/jp/qa/20190207/239003.html
- 635 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 14:11:28.61 ID:O4L9SaaX.net]
- GPUを使うようになった時点で、GetPixelのような処理はGPU側に問い合わせを送って
その結果を返してもらうという形になったから、遅くなるというのはあり得る話。
- 636 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 14:17:16.14 ID:fP398yW4.net]
- 昔はVRAMにあったものがGPUのメモリにあるわけだからね。
通常の描画処理は、CPUからは命令だけ投げてあとはGPUが処理するので
GPU内で完結するから速いんだよ。でもデータを取ってきたりするのは負荷が高い。
だからピクセル単位でとってくるよりも、一定の範囲をごっそり取るほうが
GPUに出す命令は減るから結果として速くなる。
- 637 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 15:48:36.60 ID:GjrjejsC.net]
- でもaero切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない
- 638 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 15:51:41.38 ID:u8+xJCBj.net]
- 同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ
- 639 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 16:09:15.77 ID:GjrjejsC.net]
- もう滅茶苦茶だなｗ
そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ
で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ
- 640 名前：デフォルトの名無しさん mailto:sage [2019/11/10(日) 16:51:52.04 ID:invbJGJm.net]
- Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど
- 641 名前：デフォルトの名無しさん mailto:sage [2019/11/12(火) 19:29:29.86 ID:fqP05o8Z.net]
- HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。
- 642 名前：デフォルトの名無しさん mailto:sage [2019/11/12(火) 19:33:32.19 ID:R9AMJEW8.net]
- >>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。
- 643 名前：デフォルトの名無しさん mailto:sage [2019/11/12(火) 20:44:06.06 ID:mKGma296.net]
- >>630
SetWorldTransform
- 644 名前：デフォルトの名無しさん [2019/11/13(水) 10:09:58.07 ID:OceCV+VL.net]
- DirectX使えば自由
- 645 名前：デフォルトの名無しさん [2019/11/19(火) 11:11:30.06 ID:NEogfZFa.net]
- いいかい学生さん、
「令和元年12月2n日」をな、「令和元年12月2n日」をはみ出さずに表示できるくらいになりなよ。
それが、人間えら過ぎもしない貧乏過ぎもしない、ちょうどいいくらいってとこなんだ。
|
 |
