Showing loading indicator when UI is rendering

IIRC there are some, but think about it - when UI is about to render, then the drawing area is dirty and ready to be updated. Update is about to happen. If the update takes a long time (say, 3 seconds), then even if your eventhandler/viewmodel/etc reacts to the "I'm starting rendering" event, what would you like to actually do?

Show busy-indicator? Show? That's a change. It will mark the relevant area dirty, but something already is dirty, redraw is pending, and it will take long time (3s), right? So if you show/hide anything, it will show up after the rendering finishes. That is, your busy-indicator will probably show up after 3s and will immediately hide.

That's not relevant to other things of course.. when rendering starts, you can send a TCP packet, play a sound, display another window/surface with its own independent threds (so they won't wait until first rendering finishes), etc..

I think that what you really need to do is some mixture of:

• optimize creation and data-bindings
  • do NOT load data in UserControls constructors
  • make all data-bound properties as fast to read as possible, no data-base/network access in getters, etc; return NULL, fire background Task, update property and raise changed even when data is available
  • use OneWay or even OneTime bindings wherever possible
  • don't overuse UI callbacks like events, converters, template selectors; if they are really needed, make them lightning fast
  • (...)
• working hard on limiting the number of changes to UI elements
  • maybe you dont need all of them?
  • maybe you can merge some of them to get the same effect with less UI objects?
  • maybe you can cache some ready-to-use elements so they won't need to be created?
  • maybe you can cache their visuals? meaning, rendered-bitmap cache, so WPF don't even need to render them, just tell the GPU to use buffered image?
  • if zillion of new UI elements are shown in scrollable area, you can use virtualization on UI or/and DATA elements to only present those things that really are visible right now, and trim off all those that are out of the viewport (WPF has some nice support for that)
  • maybe you can throttle the amount of UI elements to be shown at once? instead of showing a busy-indicator and a zillion of new elements and having them all show up after 3s, maybe show the busy-indicator and first 100 elements, wait some time (or until rendered), and only then start pumping further elements to be shown (again, not all at once, since probably busy-indicator will be animated and it would freeze..)?
  • (...)
• working hard to simplify UI templates for the zillion of the elements to be show, so they show up quickly
  • limit their depth (like, change a layout of usercontrol>grid>scroll>listbox>panel>[items:usercontrol>grid>listbox>panel>[items:grid>textblock] into usercontrol>grid>listbox>scrollpanel>[items:textblock]]
  • limit the amount of changes to UI elements
  • limit the amount of layout calculations (don't changes sizes if not needed, use constant values for dimensions, margins, etc, instead of calculated wherever possible)
  • use renderTransforms instead of layoutTransforms, if possible at all
  • use complex Brushes (even VisualBrushes) for complex backgrounds, instead of building them as layed-out elements on i.e. Canvas
  • in those zillions of items, limit Bindings and increase of use of resources (meaning, {StaticResource} in XAML etc) as much as possible. If you display 10k elements of different colors, it's sometimes better to define 50 item templates with colors set via StaticResources (so, redItemTemplate, greenItemTemplate, blueItemTemplate, ..) than have one commonItemTemplate that binds all of its colors from itemViewModel
  • (...)

and so on, that's the basics for starters.. Besides some basic points, optimizing WPF may actually be hard. Some further reading below, most of the articles I know from previous experience, helped me to successfully optimize many apps:

• MSDN: article with examples of WPF performance optimizations
• article about UI virtualization vs item height
• DrWPF: really useful articles, here's one of them
• MSDN: example of WPF app using virtualization, limiting/throttling, to display lots of items in canvas
• High-performance with millions of pixel graphics in WPF
• Diagnosing and measuring WPF performance w/respect to different drawing techniques

And now, to answer your question, though I still think that's not the right way:

• detect when Rendering starts: just use event CompositionTarget.RenderMSDN
• detect when Rendering ends: after rendering is scheduled, send a task on Dispatcher with Priority DispatcherPriority.ContextIdleMSDN ; source article