Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The problem is the queue priorities of the Dispatcher (see <a href="http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcherpriority.aspx" rel="nofollow">this</a>). Even if you were to respond faster to a change in the ViewModel (for example by manually updating controls), the rendering itself is done at a lower priority. Thus, I guess it won't make any noticeable difference for you to respond faster since the user won't see it under after the next rendering.</p> <p>EDIT: In general, the UI in WPF, even when doing data binding, is very responsive. However, there are some reasons why it can be slow (take a look at the app using the <a href="http://windowsclient.net/wpf/perf/wpf-perf-tool.aspx" rel="nofollow">WPF performance toolkit</a>):</p> <ul> <li>The specific control itself (which is so slow) may be too complicated/bloated. For example, I had a control which loaded a 400kb style file every time it was created. Obviously, this took some time. In my case, the solution was to load the style file in the parent control once.</li> <li>The main thread (which generally is your UI thread) does too much processing at a time. You might be blocking the thread with some long-running calculation, which means it has no chance to update the UI. So this calculation should be done in a different thread (BackgroundWorker, ThreadPool thread, ...).</li> <li>The entire UI may be too complicated. You might have an extremely deep visual/logical tree or be using large styles/templates with lots of triggers or legacy bitmap effects, etc.</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload