[Kde-games-devel] Saving overheads when resizing SVG

[Ian Wadham]

I think that the Qt::WA_PendingResizeEvent approach may be
incorrect.  I also have doubts that KDE4 main window sizing is
working optimally.  Please read on ...

On Sat, 2 Jun 2007 08:26 pm, Dmitry Suzdalev wrote:
> On Saturday 02 June 2007 08:52, Ian Wadham wrote:
> > In case you did not see Dmitry's recent commit (I only came across
> > it by chance), here is a way to avoid resizing and re-rendering your
> > SVG elements when another resize event is pending.  In your resize
> > event code do something like:
> >
> >     if (QWidget::testAttribute (Qt::WA_PendingResizeEvent) {
> >         return;
> >     }
> >
> > In particular, when the main window starts up, it generates *two*
> > resize events, one of which is "pending", so your game could be
> > rendering its SVG twice at startup time.  The above will fix that.

I seem to have completely misunderstood this Qt::WA_PendingResizeEvent
flag, so I hope nobody else has.  "Pending" does NOT necessarily mean that
another resize event is coming (queued).  Looking at the qwidget.cpp code
and reading the doco more carefully, "pending" seems to mean that a
sizing function has been done but the widget was hidden at the time, so
the resize event was postponed.  When the widget is becoming visible,
qwidget.cpp does a sendEvent() [immediate, not queued], the flag is still
true and is seen that way in the resizeEvent code.  It gets set to false after
the resizeEvent code returns.

What it amounts to is that we cannot use this flag to detect when we
have more than one resize event to handle, IMO.

> But it has a small bug, I'm not sure were it 
> comes from - windowing system or qt or both :).
>
I think the real bug, or undesirable feature at least, is that main window
causes the central widget to receive two slightly different resize events
when a KDE4 application starts up.  The difference between the two appears
to be the height of the status bar (approximately).  In a game, you can
be up for two time-consuming renders of your SVG.  Your view, Aaron?

> If you quit your app while it was in "maximize" state (i.e. you maximize it
> by hitting "Maximize" button on window header), then on the next startup Qt
> will generate ONE resizeEvent for which
> testAttribute(Qt::QA_PendingResizeEvent) will return true, indicating that
> further resize event will come next, but there isn't one. This leaves your
> app in an inconsistant state - it expected to get one more resizeEvent, but
> didn't get one :-).
>
See above, re what I think is the real meaning of "pending" in this case.
Both KGoldrunner and KJumpingCube get two events in the case above,
when the window was maximised at the time of the last quit.  KAtomic only
gets one event, though if you quit again and start again it then gets two.

The only difference I can see is the order of setup.  The preferred order,
according to a thread on kde-devel about a month ago, is:

    view = new ....
    setCentralWidget (view);
    setup Actions ();
    initStatusbar ();
    setupGUI ();

The AtomTopLevel class sets up the menu actions *before* the
setCentralWidget, but I don't know what difference that makes, if any.

> Note that this happens to me ONLY when I quit app while it is maximized.
> All other cases work perfectly as expected.
>
More to the point, the KDE4 main window should remember it was maximized
and go back to that size.  It does in KDE3.5.  Both versions have the same
info in ~/.kde/share/config/myapprc after quitting when maximised.  Width
and Height are each one greater than the monitor width and height.

Another point is that neither KDE3.5 nor KDE4 main window remembers the
"restore" size after you quit when maximized.  So if you maximize, quit and
later restart, the best you can get from a restore is a minimum/default size.

Maybe I should report these size behaviors to kde-devel --- or maybe
Aaron Seigo has some ideas about all this.  I know he has been heavily
involved in the new code for KDE4 main window and XML GUI.

Cheers, Ian W.