Re: [lmi] wx-2.8.9: slow toolbar-button repaint

[Vaclav Slavik]

On Mon, 2008-10-06 at 16:34 +0000, Greg Chicares wrote:
> If that makes sense, then should I call UpdateWindowUI() (or some
> such function) before beginning lengthy non-GUI operations?

I suspect it may actually be _caused_ by some "premature" update. When
the handler is called, toolbar button is in "pressed" state. See
Preferences button, for example: it stays pressed for a while as the
dialog is created, then it very briefly disappears and the dialog is
shown. On the other hand, Open button disappears for a bit longer as the
"Select a file" dialog is rendered.

Likewise with Help -- it takes a long time to show the frame and the
button stays hidden for, I suspect, entire duration of
DisplayContents(), all of which is executed from within the even
handler. DisplayContents() shows the frame early [*] and this almost
certainly involves some events queue processing (and therefore
repaints). Only when the handler finishes is the toolbar button redrawn
in its "depressed" state.

[*] This is a bug in itself -- it should fully prepare the content
before showing it. Showing the frame first and then filling it with
data, as is done now, is both slower and uglier.

Vaclav