int Application::run(){   while(msg.message != WM_QUIT)   {	    if(PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) // If there are Window messages then process them.	    {			 TranslateMessage( &msg );			 DispatchMessage( &msg );	    }	    else // Otherwise, do my work	    {    		    	    }   return (int)msg.wParam;}

Ohai!

First, some background: the DispatchTimer does not create another thread to run its stuff on, it is periodically checked from the WPF UI thread. This is why you can access UI elements directly and not get an exception. Now, the UI thread itself, (and here is where I start assuming stuff without any real base) is running once per rendered frame (running multiple time would be wasteful). Now, the rendering frame, my guess, is vsync ... umm... synchronized. So, no matter how small you'll set the interval of a DispatcherTimer, it won't be checked faster than your refresh rate (which, coincidentally, is almost always 60 hertz).

Now, what I would do: I would start a BackgroundWorker (which creates a different thread) and run an infinite loop in which I do my work and then sleep a bit (5 ms minus the_time_it_got_to_do_my_work_this_frame ). Now all would be nice and well if I wanted to check stuff that is "external" to WPF (like stream some stuff from the HDD, check for a network message, etc).

And from here, trouble: if you would want to access and, heaven forbid, modify UI elements from the secondary thread (our BackgroundWorker), you would have to use Dispatcher.Invoke or Dispatcher.BeginInvoke, and this is where things get messy: Dispatcher.Invoke or Dispatcher.BeginInvoke (msdn it to see the difference or PM me) do their work on the , yes, you guessed it, the Dispatcher thread (in our case the WPF UI one). And, as with everything dispatcher-driven, it is the WPF UI that checks the Invoke or BeginInvoke work queues, yep, you've guessed it, ONCE PER RENDERED FRAME.

So, if you go the BackgroundWorker route BUT you NEED to access or modify at least one UI element EVERY loop, then your update rate will slow down to 60 times per second (if you use beginInvoke this won't happen, but the UI changes will be the same - 60 hertz - in both cases).

My recommendation is (and this is a general WPF recommendation): split the UI logic from the application logic and UPDATE THE UI ONLY WHEN YOU REALLY NEED IT. So you should do your update cycle once every 5 ms, if you have to, but don't touch the UI unless when and if you really need to (and never once per update cycle).

And the real answer: i am unaware of any way to SPEED UP the WPF update cycle (but I guess it's definitely not recommended either way).

Cheers!

Thank you for the replies. Im actually trying to come up with a way of updating winForms controls in a wpf application at a rate of several hundred FPS.

My first approach was just

DispatcherTimer dt = new DispatcherTimer();
dt.Interval = TimeSpan.FromMilliseconds(1);
dt.Tick += new EventHandler(OnProcessViewports);
dt.Start();

which as mentioned, gives me arounf 60 FPS.

Ive now tried

Loaded += (s, a) =>
		    {
			    BackgroundWorker bw = new BackgroundWorker();
			    bw.DoWork += (ss, aa) =>
			    {
				    while (true)
				    {
					    Thread.Sleep(16);
					    Dispatcher.Invoke(new EventHandler(OnProcessViewports), new object[] { null, null });
				    }
			    };
			    bw.RunWorkerAsync();
		    };

This works, and gives me several hundred FPS (with a low sleep time), which is what I wanted. But, something odd is happeneing with the CPU usage. If I set the sleep time to about 16ms, then I get around ~55FPS, but, .. the CPU usage goes to about 20-30%.

using the dispatch timer approach as coded above, I get 60 FPS, and around 2-3% CPU usage. Any ideas why this would be the case? Both versions run at around 60FPS, yet the 2nd approach uses a lot more CPU usage.