I understand WPF stutter is an ongoing topic. Any help or clarification would be really appreciated.
We have a project that implements D3DImage using CompositionTarget.Render as described by MSDN. This works correctly with the exception that other UI events (e.g. update a slider value) can cause a “stutter” in playback, causing a not-smooth appearance. This behavior applies to any regular WPF app, not specific to D3DImage. I only mention D3DImage for completeness.
Simple VS2013 project (non-D3DImage) project with timing/ ETW trace info (using the Microsoft.Diagnostics.Tracing.TraceEvent package)that rotates a shape and updates a slider (directly or via databinding, inside and outside of CompTarget) is here (cannot attach files to these forums?):
http://www.filedropper.com/mywpftrace
Frame drop seems to occur for 2 reasons.
- CompositionTarget.Render is skipped for a frame (the time delta for RenderingEventArgs is 33 instead of the expected 16).
- The WPF render thread appears to either skip a frame (not render at all) or drop a frame (renders either the previous or next, not current). It’s not clear which is occurring.
RE 1 : Frame drop is mitigated if the slider’s update is issued from within our CompositionTarget.Render event handler itself, but not eliminated entirely. CompositionTarget no longer misses a call ( according to RenderEventArgs it is correct at ~16 ms / vsynced to monitor refresh rate ), however frame drop can still be perceived ( reduced to maybe 1 every 90 frames ). Additionally, it’s impossible for us to try and place all UI event updates into this call, as many controls refresh their UI in their own manner (e.g. a data bound ListBox), so this is not a realistic approach.
RE 2 : Attempting to monitor WPF native Render Thread events using an ETW listener for WClientUceNotifyPresent indicates no frame drop by the render thread, according to the event timing information which is solid at ~16.x msec.
My questions are:
Is there another approach?
As I understand it, when CompositionTarget.Render event is handled, WPF enters a “frame interlocked” (vsync) mode whereby WPF attempts to render the app at a fixed frame rate locked to the monitor vsync (forum posts, app behavior, and WPF Perf monitor seem to confirm this). Why does WPF, in frame interlocked mode, allow other UI element VisualTree changes (e.g. update slider) to also call down into the CompositionTarget.Render and the Native Render stack, causing uneven/dropped calls into CompositionTarget.Render? It seems like for a given “frame interlocked” render cycle changes to the UI Visual Tree would be accumulated then passed to the render thread once. Is there a way to ensure this?
Even with other UI interrupts isolated out, why does the WPF Render Thread still appear to drop or skip (albeit fewer) frames? Does the UI thread block the Render Thread, or does the Visual Tree not get rendered in time? and if so is there an ETW event we can trace to help detect it? (the WPF ETW events are not well documented).
If we do not use CompositionTarget, but instead issue our UI element updates using our own timing infrastructure, drawing does not appear as smooth, and still displays occasional frame drop. Is this because in “non-frame interlocked” (regular) mode rendering in not locked to monitor vsync? (We note in ETW trace long we do not receive NotifyPresent when not in “frame interlocked” mode, so we use If WPF rendering were not tied to vsync, the UI screen would presumably tear periodically, which it does not appear to.
How can we refresh our UI elements at a fixed, vsync interval that does not get interrupted by UI events that can result in frame drop? Is there any way to guarantee frame delivery short of direct Hwnd hosting and drawing to the D3D buffers ourselves?
Is there any hope WPF 4.next/5 will expose the native render thread to application developers such that we can better guarantee frame delivery, but still enjoy the blended goodness of WPF?
Thanks for any consideration. WPF is so close.