6

私は WPF の世界では比較的新しいもので、ウィンドウのサイズを変更すると、ウィンドウのコンテンツの描画がいかに遅れているかにすぐに気付きました。たとえば、ウィンドウの端にスクロールバーがある場合、それらのスクロールバーは縮小中に部分的に非表示になり、拡大するとスクロールバーとウィンドウ境界の間にスペースができます。

これは、Visual Studio で作成された空の WPF プロジェクトでも発生します。さらに悪いことに、背景でも発生し、拡大するとウィンドウの背後にあるもの (他のウィンドウ、デスクトップの壁紙など) が漏れ​​て見えることがあります。

最初は、ネイティブ アプリケーションまたは WinForms アプリケーションのサイズが適切に変更される (適切に記述されている場合) という WPF の醜い制限だと思いました。しかし、Expression Blend を見ると、ウィンドウの背景は不透明のままです (ただし、ウィンドウのコンテンツはまだ遅れています)。説明されている問題を防ぐために彼らは何をしていますか?また、より近似したネイティブ/WinForm GUI へのサイズ変更を改善する方法はありますか?

4

5 に答える 5

3

ラグの理由はここでうまく説明されています

于 2010-01-20T03:53:35.117 に答える
1

SP1 なしで Vista を実行していますか? 私が読んだことから、これは修正されたと思われる一般的な問題でした..

http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/3960d6a6-e873-455c-9ddc-1e2dd32e090b/

于 2009-02-17T02:43:38.767 に答える
0

サイズ変更中にインターフェイスが遅れるという同じ問題があります。ラグの理由は、直接Xで基になるフレームバッファのサイズを変更することであると思われますが、これは特に高速ではありません。しかし、あなたがそれについて何ができるかはわかりません。

于 2009-02-20T03:02:49.443 に答える
0

私もこの問題に関する情報を探していました。勇敢なマイクロソフトのプログラマーがクールだと思ったのは、Windowsの「機能」だと思っただけです。ウィンドウのサイズ変更が遅れてオーバーシュートするのではなく、実際にマウスに追従するようにオフにできることを望んでいました。ぐら。

于 2009-04-10T15:24:26.650 に答える
0

私自身、この動作は見ていません。vista x64 sp1 および/または xp x32 sp3 を実行する仮想 PC で開発しています。Wpf は directx を使用していますが、それはビデオ カード/マシンでしょうか? アプリを diff マシンで実行してみて、同じ結果が得られるかどうかを確認してください。

于 2009-02-20T01:51:09.680 に答える