[Workaround found - described in thread] Refresh Issue

[daves]

I'm continuing to struggle with some subtle issues with my image browser implementation.

The current struggle relates to a seeming "refresh/leakage issue". I've run several experiments with this issue to try to isolate; so far to no avail.

I'm back to my 3 image experiment. The framework for this experiment is described in a separate thread focused on "scrollable pane management". This "refresh/leakage issue" seems to be independent of the "ScrollablePane issue" (in fact I changed the pane to a simple default window and still see the refresh issue); hence I created a separate thread for this one. For reference see: http://www.cegui.org.uk/phpBB2/viewtopic.php?t=3314

The framework that I'm using only differs subtley from the framework described in the attached link, in that I've added an additional container in order to "preserve the aspect ratio of my images".

In the first picture I show the 3 images within a simple framework:


In the second picture you see the "leakage":



Here the image window is shown though its parent is clipped (I have checked and rechecked to ensure that I have "clipped by parent" set to true for pretty much every window in this heirarchy - and certainly for the image window itself)

Now I simply move the framewindow (or move the scrollbar) and all of a sudden the image is clipped (correctly):



What would cause this kind of thing to happen? As I said though moving the scrollbar results in a refresh, I have observed the same behaviour when I replace the ScrollablePane with a simple DefaultWindow. I also observe this behaviour when I replace the StaticImage (that which contains the actual image texture) with a simple Button.

[daves]

Another manifestation, pretty indicative that this is NOT a "clipped by parent issue". This picture follows "picture 3 above". I now increase the framewindow and see that the image content is not drawn. Again if I now move the framewindow then voila the images show up.

[daves]

To rule out the image window, as mentioned above, this occurs with simple buttons too:



and then



and then simply moving the frame:



Just a thought.. I saw something such as this recently and I ended up finding a work around which had me eliminate a container window that I had been using. The only thought that has come to mind is a question "could it be something that relates to the depth of my window heirarchy that creates this issue"? Of course, the persistent question/thought is "what am I doing wrong, I must be doing something stupid somewhere"!!

[daves]

I have a workaround. Simply by installing a resize handler on the framewindow and then calling mFrame->notifyScreenAreaChanged() the resize "leakage" goes away.

I'm now searching the forums to see if this is a known bug...

[CrazyEddie]

Hi,

I can't explain the clipping issue at the moment, it's very odd - especially since you get that 'snap' back to correctness when you move the window a bit (remind me, which version of CEGUI is this?)

Your point about limits to the depth of the hierarchy is actually very valid - there is actually a limit to the number of windows you can have (1000 or something) - and at this point parts of the rendering start to disappear and re-appear as you navigate through the windows (this is due to a value set in the renderer base class, I guess you could adjust this and rebuild if you do hit that limit).

CE

[daves]

Please confirm that 1000 is the limit to the "child depth" not to the total number of windows. I'm sure I have more than 1000 windows in all, I also know (or at least am highly confident) that in terms of child depth I should be no where close to 1000 (that would be insane ).

[daves]

Hi,

remind me, which version of CEGUI is this?


CE

0.5.0 with a couple of simple patches applied from the latest baseline (e.g. the slider thumb dissappearing patch).

[CrazyEddie]

Please confirm that 1000 is the limit to the "child depth" not to the total number of windows. I'm sure I have more than 1000 windows in all, I also know (or at least am highly confident) that in terms of child depth I should be no where close to 1000 (that would be insane ).

I had a look at this, and it seems the limit is set to be 1000 windows - this is from way back when, and is, thinking about it now, actually something I don't like very much at all, so I'll be eliminating this limit completely in the future.

You need to look at CEGUIRenderer.cpp to change this, and update the Renderer::GuiZElementStep and Renderer::GuiZLayerStep (what's this for?) values.

0.5.0 with a couple of simple patches applied from the latest baseline (e.g. the slider thumb dissappearing patch).

Hmmm, I think that was the patch issue that fixed what I thought this might be, hehe

CE.

[daves]

0.5.0 with a couple of simple patches applied from the latest baseline (e.g. the slider thumb dissappearing patch).

Hmmm, I think that was the patch issue that fixed what I thought this might be, hehe

CE.

Wait.. this could be related then.. I did not apply the "slider thumb patch" in the way that you might expect. It was not an official cegui patch, rather you pointed me to the single file "FalagardSlider.cpp" that was fixed.. I took just that file and applied it as a "custom patch"; performed in this fashion because I wanted to limit the changes introduced. So this was an extremely localized/customized patch. In the near future I hope to bite the bullet and jump into a full upgrade to 0.6.0, but until then this is largely a 0.5.0 build. Can you point me to some other fix that you had in mind? I can check to see if I have that in my distribution.

[CrazyEddie]

Hi,

Ok, I did a little digging. I think the issue would have been fixed as part of a different issue...

Log message:

FIX: Invalidating only cached clipped areas for a window was not having the desired effect on child content. Fix addresses http://www.cegui.org.uk/mantis/view.php?id=165

The patch for that fix is as follows:

Code: Select all

Index: src/CEGUIWindow.cpp
===================================================================
--- src/CEGUIWindow.cpp   (revision 1535)
+++ src/CEGUIWindow.cpp   (revision 1536)
@@ -3175,6 +3175,10 @@
 {
     d_screenRectValid = false;
     d_screenInnerRectValid = false;
+    // make sure everything gets redrawn now that clipping has changed.
+    // NB: this way may not be not ideal, but invalidating the clipped rects
+    // only did not have the desired effect.
+    d_screenUnclippedInnerRectValid = false;
 
     // inform children that their clipped screen areas must be updated
     const size_t num = d_children.size();

HTH

CE.

[daves]

CE,
Thanks for digging. I thought for sure this would be it. I tried that patch and it did not seem to work. I noticed that CEGUI::Window::onSized and CEGUI::Window::onMoved are slightly different in structure. Interestingly onMoved calls notifyScreenAreaChanged on all the windows children (onSized does not), and sure enough calling it in my FrameWindow resize callback was the workaround I applied yesterday.

At this point I'm keen to try out 0.6.0. Its something that I should have done anyways, I just havent had the time to move forward.

I may just take a crack at this, in reality I think I can pick up 0.6.0 and in a day, two at the most, have it integrated. I dont believe there are the kinds of breaking changes going from 0.5.0 to 0.6.0 that there were moving from 0.4.0 to 0.5.0, and even with these changes a 0.4.0 to 0.5.0 migration only took about a week (and I had far less comfort with CEGUI then).

Do you have any recommendations for things I should be looking out for in a migration to 0.6.0? Are there specific breaking changes that I should be keeping in mind?

Thanks for taking all the time.

[CrazyEddie]

I dont believe there are the kinds of breaking changes going from 0.5.0 to 0.6.0 that there were moving from 0.4.0 to 0.5.0

This is correct; the 0.4.x to 0.5.0 migration was a huge headache for one and all. The subsequent upgrade to 0.6.0 should be largely painless.

Do you have any recommendations for things I should be looking out for in a migration to 0.6.0? Are there specific breaking changes that I should be keeping in mind?

I believe there are only really a couple of potential gotchas when moving from 0.5.0 to 0.6.0...

First is related to a change in the way the system marks handled mouse button down events - the situation now is that they're only marked as handled if the system does something in response (i.e. it's technically correct), but this means that clicking on an inactive window twice will result in two different responses - the first event will be marked as handled (as the window was activated), while the second event will not be marked as handled, since the window is already active and the system does nothing in response. This will then lead to the event getting passed back up the window hierarchy until it's either handled or we run out of windows. This recursive behaviour is incorrect as far as I am concerned, and will be looking at it again in 0.7.0. Anyway, the long and the short of it is, that you need to be careful, especially if you rely on the boolean return value from the input injection functions.

The second issue is due to an ill fated change made to the System::setDefaultXMLParserName static member. If you're using this in 0.5.0 in 0.6.0 it basically does not work - it actually does something totally different - although this issue is fixed in the v0-6 branch, and will be working correctly again in 0.6.1.

I think aside from these couple of points there is nothing really to worry about - though if Eddie is truly crazy, some or all of the above may be totally wrong!

CE.