>>117
ところが、このランレングス法は、アプリを最初に起動した直後に一度だけ行うことを想定している
らしいことと、ランレングス法を使っていることで、透明色のON/OFFが非常に激しく変動すると
ランレングスデータが大きくなってしまうことも有って、ものすごく時間が掛かる。
ものすごくといっても、1/60秒に比べて遅い程度。しかし、やっかいなことに、これが
X-Windowのコマンド・バッファ(?)に「蓄積されてしまう」。

で、Windowsの場合、このように描画が遅い場合は、Invalidate() 系の関数が自動的に処理の
頻度を遅らせてくれたりするようになっているので問題にならないが、Wineは、それが上手く
模倣できていない。調べてみると、もう忘れてしまったが、X-Windowのコマンドバッファが
たまっているか、空いているかを調査する関数が正しい値を返さなかったり、また、
処理のフラッシュが沢山の種類があるが、どれも、本当の意味でフラッシュしてくれなかったり
することで、結果的にエミュレートが出来ないことになっていることが分かった。
思い出してきたが、「Xのコマンドをフラッシュして処理が終わるまで帰ってくるな」
という意味の関数を呼び出しても、実際には、Xの描画が終わって無いのにすぐに帰ってきたりする。

実は、このことと絡んで、WM_TIMERもちゃんとエミュレートできていない。WM_TIMERも、
Windowsでは優先順位の最も低いメッセージの一つで、画面処理が遅いような場合は、
システムが適当に間引いてくれることで、異常な処理の遅さを回避できているのだが、
Wineではそれが模倣できていない。この理由も今述べたようなことが複合的に重なって、
での仕組みを使っても模倣できない事態になっていた。