[Kde-games-devel] Extra resize events from KXmlGuiWindow

[Parker Coates]

On Tue, Mar 24, 2009 at 12:46 AM, Ian Wadham wrote:
> On Tue, 24 Mar 2009 1:30:41 pm Parker Coates wrote:
>> In the KDEGames camp we've run into a small bit of trouble with
>> KXmlGuiWindow generating an extra resize event on startup. An extra
>> resize event may seem trivial enough, but because our games now all
>> have resizable SVG based interfaces, a single extra resize event can
>> mean extra SVG rendering, cache lookups, layout logic and a noticeable
>> increase in start up time.
>>
> There are several threads on this problem in the KDE Games list about
> 15 months to a year ago.  There can actually be 1, 2 or 3 resize events
> from KXmlGuiWindow, depending on the user's previous setup, and it
> is apparently not possible to determine which is the "last" one.  The
> following thread discusses the workaround I used in KGoldrunner:
>
> http://lists.kde.org/?l=kde-games-devel&m=120071267328984&w=2

Hello Ian,

I remember that thread, but thanks for linking to it as it provides
more technical detail than I did. As far as I know, you never brought
it forward to the wider KDE developer audience, so hence my mail.

I also should have mentioned your KGoldrunner solution. While it's
quite clever and works well in KGr, it is definitely a workaround and
doesn't apply as cleanly to all apps.

> It also describes the various behaviors of KXMlGuiWindow with respect
> to resize events and AFAIK still represents the state of play in KXmlGW.

I would agree. Out of interest's sake, I will point out that it seems
there have been changes since pre 4.0. KPat contains some code to mask
the extra resize events that was added during the conversion to Qt4.
Apparently it worked at the time, but it doesn't anymore. By the way,
KPat is the app where this problem is currently most noticeable. It
animates on resize, so when the game is fired up, the first thing you
see is all of cards bunching together as a result of the extra resize.

Parker