WPF in Task Pane has nasty Flicker

[aberglas]

Hello Govert,

I have a task pane with a moderately complex WPF user control in it,
which involves Flow Documents, and seems to take about 15ms to
render. It seems that the flicker happens during the render.

The flicker is not just to white, but to black, which makes it look
quite bad. Or sometimes bits of the Excel graphics end up in it.
Have tried setting background colors of everything -- wpf control,
elementHost, containing form.

I'm not sure whether this is an ExelDna issue or a Wpf/Excel one. It
is worse with ExcelDna than VSTO, but it is also very variable for non
obvious reasons -- it gets better over time!

I am actually driving the .Net from VBA via com. I update the display
by
m = new Model();
m.properties=...;
DataContext = m;
Ie no events to confuse things. (The model is completely different
each time, so this should also be faster.)

It seams to be more of a WPF issue, not winForms. In both .net 3.5 and
4.0. Excel 2010.

It is difficult to reproduce in a small example. But by updating a
WPF model 100 times from VBA, DoEvents between, and ScreenUpdating =
*False* it flickers a bit. ScreenUpdating = True smooths it out(!). I
think because in a small example each of the 100 WPF redraw is very
quick, and the XL cleans it up before you can notice.

Doing the 100 updates within .Net does not flicker, even with a

wpf.Dispatcher.Invoke(System.Windows.Threading.DispatcherPriority.Render,
EmptyDelegate);
between them which seems to force the update to the screen.

Any ideas most welcome.

Anthony

[Govert van Drimmelen]

Hi Anthiny,

That sounds like a tricky one!

When you create a Custom Task Pane via Excel-DNA, it is only involved
in the initial hookup, to do the on-demand COM registration. Excel-DNA
has no involvement or interference in the CTP as it runs - no wrappers
or anything in between. Perhaps VSTO has some wrapper code that might
make it integrate better - you might discover this by poking around
the VSTO library with ILSpy a bit, and then implement the same code in
your add-in.

There used to be some issues with WPF being hosted in Office apps, but
I have no experience myself or a nice reference at hand. Before you do
the complicated-sounding VBA/COM updating, just check whether you can
update the content of your CTP fast enough from a timer or something.
I don't really understand your update loop - it might be that you are
just doing too much work on the main thread. DoEvents is pretty much a
red flag to me. The interaction between Excel's ScreenUpdating and how
the CTP is hosted is a mystery, but maybe someone on the Excel for
Developers forum might ahve some ideas.

So my suggestion would be:

- If you really see a difference between Excel-DNA and VSTO, then it
is due to code that is in the VSTO libraries setting some confguration
or doing something clever to the UserControl. Excel-DNA is not
involved in the WPF/CTP drawing path at all.

- Make an example of a WPF form outside Excel, which matches the
content that you want to draw, and check that you can update it at the
rate you require. WPF has a million tuning options, like bitmap
caching, that can make a huge difference to its performance.

- Next, make a WPF/CTP that displays the content and is updated from a
timer or something - no VBA/COM or Excel involved in the updates, just
hosted in Excel. This will test the hosting in the WinForms host and
Excel, and give you confidence that the message loops and display
environment doesn't mess anything up.

- Next, update the data from .NET code in your add-in, allowing you to
figure out any threading issues, since your updates will probably be
generated on a secondary thread, and you need to update the WPF
controls on the main thread.

- Finally, consider you to hook up the real data.

Good luck!

Govert

[aberglas]

Hello Govert,

Thanks for your reply. I suspect some sort of a Excel/WPF
interaction, will look at WPF tuning. I once had a vaguely similar
problem with Winforms double buffering.

WPF is fast enough (10ms) but it is the flicker to black during this
time that causes grief.

The reason for the DoEvents, or Timer, or wpf.Dispatcher.Invoke is to
force an actual render. Otherwise WPF will do nothing, just
invalidate objects.

I will experiment further, but I may just have to live with the ugly
flicker.

Regards,

Anthony