[MD:1152]scroll-bar synchlonized redraw test.

[Miyashita Hisashi(宮下 尚:HIMI) <himi@xxxxxxxxxxxxxxxxxxxxxxxxx>]

今までスクロールバーをつかんでスクロールさせても、
もどかしい動きしかしませんでした。

1.04a1でも、しくみはそれほど変わっていません。

問題は、MeadowのEvent Handlingの特性によります。

Meadow のEvent送出部は、優先度の高い
別スレッドになっていて、スクロールバーを動作しているときは、
お構いなしにeventをqueueに突っ込みます。

Emacsのevent処理部は、まだ未処理のeventがある限り、
再描画しません。

しかし、素のWindows NTは、やたらとcontext switchが重いらしく、
スクロールバーを動かすと、Kernel LaryerのProcess Timeが相当
食われます。

というわけで、せめてもの慰みで、Emacs Lisp部分の最適化を行いました。

Cyrix M II 300MHz程度の私のマシンではそれほど効果は出ていませんが、
前よりもたつきは少なくなりました。それにしても、Emacsはdynamic bindingの
処理に結構きついものがあるんですねぇ。

とはいえ、Visual C++ 6.0でフルに最適化をかけた結果、結構快適になりました。

しかし、VC++6.0の最適化はかなり賢くなっていて、Frame pointerとか
Registerの使いまわしをがちがちに最適化するので、
デバッグがVC++5.0よりも飛躍的に辛くなります。
というわけで、皆さんにお配りするAlpha/Beta版binaryは最適化しません。

# また、どうも、VC++6.0の最適化にもバグがあるかもしれないので、
# こちらでも慎重にテストしています。

しかし、Compilerの最適化というのはすごいものがありますね。VC++の
RegisterとかFrameの使い方はすばらしいものがあります。

まあ、だれか、PentiumII-400MHzとか、K6-IIIのマシンとかで
スクロールをためしてみてください。

### いかん、酔った頭でこういう最適化するとは...^^;;;

from himi
1.05の目標はDLL分割 + DelayLoadかな？
それとも、そろそろIMMにけりをつけるのかな？
まあ、優先順位からいくとIMMかな。