[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: [MD:7171] GET/RELEASE_FRAME_HDC と FRAME_HDC の使い分け



張本人です.

> > もしそうなら、都度 DC の取得/解放を行なうように変更し、FRAME_HDC を廃止
> > した方が良いのではないかと思います。
> 
> 賛成です。

 FRAME_HDC を作った意図はは大方の予想に反して基本的に高い確率で
(^^;)GetDC が不要なコンテクストでかつ RELEASE のタイミングが多い
(分岐中での return が多い)時に RELEASE_FRAME_HDC を省ことにありま
す. パフォーマンス的には GET_FRAME_HDC とほとんど変わらないと思い
ます.

 というわけでちょっと RELEASE_HDC が増えてしまいますが, FRAME_HDC
は使わない方がが安全だと思います.

> まえにframe_hdcをごちゃごちゃいじって失敗してるコードを見たときに
> 同じようなことを思いました。
> ぜんぶGetDC()/ReleaseDC()にして、パフォーマンスの変化を見てみて、
> 気にならないなら移行してしまうというのでどうでしょう。
> パフォーマンスの測定方法としてよい案があるわけではないですが。

 話を単純化しているのだと思いますが, *_FRAME_HDC はメインスレッド
とメッセージスレッドの間の同期を受け持っているのでそのまま
GetDC/ReleaseDC にされてしまうとちょっと困ります.

 それから結局HDCが必要となるタイミングが実行ルートによって変化する
ので同期機構を分離して hdc の取得/解放を単純に GetDC/Rrelease にし
てしまうと多分少なくとも3レベルのネストは発生すると思います. 複数
のフレームが同時にこれをやると多分 GetDC に失敗してしまうこともあ
りえます(hdc プーリングをやっていた以前の実装では時々失敗していま
した.) なので生で GetDC/ReleaseDC をすることには私は否定的です.

 というわけでとりあえずのこの部分に関する対策としての私のオススメは,

 ・BLOCK_INPUT を Meadow で正しく動作するようにする(かつパフォーマ
   ンスの低下を抑える..)

 ・hdc の多重取得の制御を今よりもっと単純な方法で実装する.  (すく
   なくとも素直に関数の形にしてインライン宣言をするくらいはしてお
   く?)

-- 
ほりぐちきょうたろう