Add event to signal WPF rendering completion - by Christoph Nahr

Status : 


Sign in
to vote
ID 380674 Comments
Status Active Workarounds
Type Suggestion Repros 5
Opened 11/8/2008 1:25:15 AM
Access Restriction Public


WPF performs the final steps of screen rendering in a background thread, and while there are several events that fire when layout is complete, there is apparently no way to tell when the actual on-screen rendering has finished.  This is extremely annoying when rendering takes a noticeable amount of time and the application cannot show any sort of wait cursor, progress bar, etc. to the user, since we cannot know when to revert to normal operation.
Sign in to post a comment.
Posted by Microsoft on 11/15/2012 at 3:28 PM
The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.

We appreciate the feedback. However, this issue will not be addressed in the next version of WPF. Thank you.
–WPF Team.
Posted by bojingo on 6/2/2011 at 11:50 AM
The workarounds don't sound particularly intuitive for something that should be relatively trivial.
Posted by Christoph Nahr on 1/13/2011 at 12:15 AM
Thanks for the reply. The fact that the Rendering event parameter is actually a RenderingEventArgs object is a rather well-kept secret that I wasn't aware of. I asked the MSDN Library team to update the Rendering event page with a link to this type.

However, after some experimentation I fail to see how the RenderingTime property would help with our issue here. RenderingTime gets updated for each frame, 60 times per seconds if possible, even if there isn't any new content to render. Since we want to know when content has been rendered that doesn't really help us. On the other hand, completion of all scheduled display updates might take several frames, so we can't just wait for a single frame to finish either. Unless I'm missing something it seems that hooking Rendering is a dead end for this particular issue.

LayoutUpdated has a similar problem -- from an application perspective it gets called an unpredictable number of times, so we can't know for sure which call was the last one for our current set of display updates. One could use a helper timer that fires some time after the last LayoutUpdated call, though... that might be worth a try.
Posted by Microsoft on 1/12/2011 at 10:46 AM
In addition to the potential workarounds mentioned already, this info could be considered:

The UI thread “renders” by computing render data and sending it over the channel to the render thread. In this sense, rendering is often correlated with layout, so events like LayoutUpdated can be used.

The UI thread can also enter so-called “interlocked” rendering mode where it coordinates with the render thread to synchronize with the vblank. This coordination can be used to determine when the render thread has presented. Hooking the CompositionTarget.Rendering event and monitoring the RenderingEventArgs for a new timestamp is pretty effective.

Thanks, WPF Team
Posted by Jan Kučera on 8/10/2009 at 5:31 AM
Maybe adding a blocking call which chould be called from the background thread is a good one too.

By the way, you should be able to get that event when you assign a task to the dispatcher with low priority, so that it will be executed after the rendering. Though this helps in most cases, some more reliable solution would be surely welcomed.