[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?

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.


- Alan


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


On 2009-05-02 07:04:33, Alan Alpert wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/653/
> -----------------------------------------------------------
> 
> (Updated 2009-05-02 07:04:33)
> 
> 
> Review request for KDE Games.
> 
> 
> Summary
> -------
> 
> When KAtomic is started the background image doesn't fill the window. Note that this is only the first time you start KAtomic so you'll need to delete katomicrc (and it's not guaranteed, but about 90% of my tests without katomicrc had this issue).
> 
> I don't know why it's testing Qt::WA_PendingResizeEvent, which seems to me to be primarily for Qt internal use. The first resize event usually has that attribute, and so the playfield widget isn't sized right (unless another resize event happens, like loading previous geometry from the config file). I placed "&& false" into the condition on line 239 and it always resized correctly, fixing this bug.
> 
> I am working from the assumption that this if statement is not neccessary, as I do not understand it's purpose. This is not necessarily true, and should this if statement be important then a more appropriate fix will be needed.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdegames/katomic/gamewidget.cpp 962418 
> 
> Diff: http://reviewboard.kde.org/r/653/diff
> 
> 
> Testing
> -------
> 
> Bug was successfully reproduced from an initial sighting in KDE 4.2.2. using svn trunk at r962430. The bug seemed resolved over mulitple trials of deleting katomicrc and running the application after the "&& false" was added. The attached patch was then created. It was tested that the attached patch compiles, however running KAtomic was not tested with the below patch (though it shouldn't differ from the case with "&& false" in the condition).
> 
> 
> Screenshots
> -----------
> 
> The undesired behaviour
>   http://reviewboard.kde.org/r/653/s/110/
> 
> 
> Thanks,
> 
> Alan
> 
>