CEGUI (Crazy Eddie's GUI) Forums

Hey everyone,

I recently wrapped some of my UI items in SequentialLayoutContainers in order to give me greater flexibility in what is displayed in my UI windows. I'm running into an issue though where setting the position of the parent window (via SetPosition()) is not updating the position of the container, leaving its child elements in their old position. If I remove the layout container, everything works as expected.

Here's part of the layout for the window:


Here's the code updating the position


Any thoughts on why the update to the position is not being propagated properly? Thank you in advance for the help

CEGUI Info

Is there any chance you could try out v0-8 from the repository? we recently fixed a bug regarding FrameWindow positions not being propagated properly to the children. It could be related.

Do you mean 0.8.7 for CEGUI? I'm not using CEED, which is what appears to be a v0-8.

I can certainly try it; will take a bit while I set everything up.

v0-8 is a CEGUI branch, not CEED. There is also a CEED branch v0-8 but that is just made to go along with CEGUI v0-8.

Link:
https://bitbucket.org/cegui/cegui/src/c ... 1/?at=v0-8

This is what is going to be 0.8.8

Ah, I see. I'll DL it and let you know what I find. (Will be a bit)

Updating the version to the 0-8 branch did not make a difference :-/. The child elements remained in the old position after the parent window of the LayoutContainer was moved.

In order to debug this better, how are positional updates propagated to the children? Is it somehow different from dragging? Because that works without issue.

Edit:
I tried tracing the behavior of the window ( concentrating on Element::notifyScreenAreaChanged() ) and compared the behavior of a mouse drag with the setPosition() call (basically, the one that works and the one that doesn't). As far as I can tell, there is little difference between the two; the children of the LayoutContainer do get called during this updated. I'll keep digging, as the difference should be here.

Brief Update: Updating the size of one of the child windows inside the LayoutContainer after the position of the parent window has been modified results in the child position being updated properly. Could the child window not be getting properly set to dirty when inside a layout container? (Though, I admit, that it appears that it is; at least notifyScreenAreaChanged() is called on it)

Any thoughts on where to look next, Ident?

LayoutContainers are relatively new compared to some other widgets, there could easily be bugs.

I did not write them so I got no clue where to look next, I probably know as much as you at this point and would just have to do what you are doing.

What you can try is to call notifyDisplaySizeChanged on the child after the parent container position was changed. If this changes something then this likely means "something" wasnt set dirty that probably should have.

Al'right, this has taken me down quite the Rabbit Hole, but I believe I have an answer.

When the position of a Window is set ( Element::setArea_impl() ), it first invalidates its unclipped rects (both outer and inner), updates the size of its area, then propagates the changes to its children through the onMoved() event.

The children follow a similar pattern ( Window::notifyScreenAreaChanged() ), first invalidating their own unclipped rects, passing the event to their children, then updating their geometry. As the children update their geometry, they make calls to Element::getUnclippedOuterRect() which, since it was invalidated previously, now gets recalculated in Element::getUnclippedOuterRect_impl(), which itself updates the outter rect for the parent.

The problem for LayoutContainers, as I see it, is that they only mark their unclipped rects *AFTER* they've passed the notifyScreenAreaChanged() to their children. Specifically:



This means all the children are re-calculating their position with the old position of the layout container. If you perform a change to any of the LayoutContainer's children after the original call to setPosition(), the children will correctly update the LayoutContainer's area (since it was marked dirty) and be updated correctly.

This actually explains why mouse dragging works... or at least appears to. The fact that my app is going at 300 FPS means that, at most, positional updates are going to be 1 or 2 pixels away from the last update, so I'd never really notice.

My fix was the following:



As far as I can tell, positional updates are now being carried out correctly (in my brief test case). Does this seem like a valid analysis? Would this change hurt anything else?

I do not see what could go wrong by doing this. Have you played around with it enough to be confident about it being non-breaking? The sample browser uses a bunch of layout containers if I remember right , so that might be a good case to test. If you want you can make a pull-request on v0-8 and i ll look at it.

I will do so, but give me until Monday. I promised myself a bit of time off this weekend

I will even give you time until Wednesday!

I tried out the changes on a few of my UI elements which are heavy on layout containers (both Horizontal and Vertical; haven't tried Grid) and, as far as I can tell, everything is working as expected.

The pull request should be on your desk. (If not, here's the link). Let me know if there's anything else you need.

You need to make a PR against the official CEGUI bitbucket, not against your own fork
https://confluence.atlassian.com/bitbuc ... 20593.html

Sorry about that; first time using BitBucket.

Updated link!