[Kde-games-devel] SVG and MainWindow resize handling

Ian Wadham ianw2 at optusnet.com.au
Sun Jan 20 04:51:56 CET 2008


On Sun, 20 Jan 2008 06:00 am, Burkhard Lehner wrote:
> 2008/1/19, Dmitry Suzdalev <dimsuzkde at gmail.com>:
> > On Saturday 19 January 2008 19:40:12 Burkhard Lehner wrote:
> > > You could check for every paint event if the window size has changed
> > > until the last paint event, and render the SVG graphics only if needed.
> > >
> > How would you determine which paint event is *last* in series of paint
> > events?  :)  If you have some way to determine that - it would solve
> > all these problems.
>
With conventional main window widget constructor code (as we have
all been using), the first central widget resize event occurs *during* the
main window's show() operation (i.e. it is not queued).  The second one
occurs on the queue, after your constructor exits.  The third (the
maximized case) occurs about 100 msec after that (on a further scan
of the queue).  I imagine all three would be accompanied by paint events.
So indeed, how do you tell which is the *last* paint event?

My new approach makes all these events occur at predictable moments,
before and after the constructor extension (with its delayed show()) ...
and without any artificial time delays.

> What about scanning through the event queue, if there is still a pending
> resize event? If so, better don't paint anything, and don't render any SVG,
> because it will be void for sure a few milliseconds later.
> Maybe I again miss something.
>
I looked at that, but could find no way to directly read a Qt app's main
event queue.  Even if I could, how would I tell which is the *last*?  As soon
as I give back control, the library might schedule another one.  And
there is also such a thing as sendEvent(), which is not queued at all ...

I also spent a lot of time looking at the code of KXmlGuiWindow,
KMainWindow and friends, to see if the resizes could be condensed
into one (as I would think might be logical), but it is actually rather
difficult (for me) to find out exactly where the resizes get triggered
and the code is not generous with comments either.  So I am
forced to continue regarding the main window's library code as
a black box ... :-)

All the best, Ian W.


More information about the kde-games-devel mailing list