[Kde-games-devel] Review Request: KAtomic first run resize bug

[Alan Alpert]

> On 2009-05-02 08:33:45, Albert Astals Cid wrote:
> > Other programs, e.g. Klines, have the same problem, the thing is that the code seems correct to me, might it be a Qt regression?
> 
> Alan Alpert wrote:
>     A simple example (not katomic because kde from svn says it needs >= 4.5) had this same behavior where a resize event with the attribute set will come without being followed by another resize event. This behavior was observed with both Qt 4.5.1 and Qt 4.4.3 so I don't think it's a regression. 
>     
>     I'm still not clear on the purpose of the widget attribute, so I can't say it's worth the hassle. I'm going to quickly look into alternative ways to avoid the multiple resizes though.
> 
> Alan Alpert wrote:
>     Best optimization I've thought of so far would be to only 'accept' one resize event every 300ms or something like that. Not as good as what the current solution is supposed to do. I'll see if I can't somehow get clarification from the Qt guys as to what Qt::WA_PendingResizeEvent is supposed to be, so as to determine if this is a Qt bug or we were using it wrong.
> 
> Albert Astals Cid wrote:
>     Well, documentation states "Indicates that a resize event is pending, e.g., when a hidden widget was resized. This flag is set or cleared by the Qt kernel.", doesn't really state if it's valid to check it inside the resizeEvent itself.
>     
>     Your solution seems a good idea, but 300ms is a lot, doing some testing with katomic the second resize events comes after 3/4 msec of the first, so 10ms seems a good top level for that.
>     
>     My suggestion is having a timer with timeout of 10ms that really does the rendering and that is restarted each resizeevent, are you up for trying to code such a patch?
> 
> Alan Alpert wrote:
>     Yeah, I can code it up. I'm currently now leaning towards a slight variation where we ignore resizes for some duration at the start, and then resizes to whatever the last resize was. If the delay is just right than it will ignore 1-3 resizes and only do one resize. It probably would be best to have the main view only show after that resize to avoid the possibility of a few frames un-resized being shown, as we won't be synchronized to Qt's drawing anymore.
>     
>     I'm also not sure about the duration, as we aren't counting by clock cycles and it needs to be long enough for slower computers (who REALLY need to avoid multiple resizes). I don't have a slower computer though so I can't test that :). I suppose we can just try different values, it's easy to change a single value.
> 
> Albert Astals Cid wrote:
>     So, after the discussion on mailing list i guess this patch is "on hold"?
> 
> Alan Alpert wrote:
>     I've looked into the WA_PendingResizeEvent flag, and it is not valid inside a resize event (technically in 4.5.1 inside a resize event it means that resize event was triggered by that flag). So it was not actually being used properly. Not that one can expect everyone to check the Qt source before using a widget attribute.
>     
>     What we really need to know is whether another resize event will happen in the near future. Only way I can think of to get that is to wait until they add clairvoyance to QFuture :) .

Note that that previous comment was written May 3rd, but I forgot to hit the 'publish' button on review board.

Back to the present, yes the patch is on hold pending the solution of the underlying problem.


- Alan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/653/#review1029
-----------------------------------------------------------


On 2009-05-03 20:35:17, Alan Alpert wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/653/
> -----------------------------------------------------------
> 
> (Updated 2009-05-03 20:35:17)
> 
> 
> Review request for KDE Games.
> 
> 
> Summary
> -------
> 
> This fix only does one resize after startup, or at least in the first N ms. I'm not sure about the value of N but 10ms worked for me, probably due to the event ending up later in the event loop than the resizes (or 10ms being longer than it takes to load katomic without a resize on my pc, also possible).
> 
> While this approach does prevent the original problem in the screenshot and also only performs an expensive resize once it does have the drawback that an empty window (or the unsized one in the screenshot, but I think empty is better) is shown for at least one frame in the period between the application having started and the resize finishing. There are three ways I can think of to deal with this more minor bug.
> 
> 1) Show a 'Loading, please wait' screen for that split-second, like plasma applets.
> 2) Store a precalculated image, probably saved on last application exit, and show that before hand, which will be slightly off but fast and the difference probably won't be as noticable as a large white expanse.
> 3) Don't worry about it - it's only a split-second while starting up. If it really does only do the resize once then even on slow computers it should finish loading before the users thinks something is wrong.
> 
> If there is a convenient way to do option 1 with KDE's libraries (like there is in plasma) then option 1 might be worth the effort but otherwise I'm leaning towards option 3.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdegames/katomic/gamewidget.h 962713 
>   trunk/KDE/kdegames/katomic/gamewidget.cpp 962713 
> 
> Diff: http://reviewboard.kde.org/r/653/diff
> 
> 
> Testing
> -------
> 
> KAtomic @r962713 with the patch compiled and ran without error, with and without katomicrc, save the issue explained above. Debug statements indicated that in all tests I did the one or two resizes at startup were ignored and then one was done later, as intended.
> 
> 
> Screenshots
> -----------
> 
> The undesired behaviour
>   http://reviewboard.kde.org/r/653/s/110/
> 
> 
> Thanks,
> 
> Alan
> 
>