[SOLVED]Resizing a FrameWindow causes slowdowns

[Jamarr]

I thought to myself the other day that I don't think I'd ever seen a game that had user-resizable UI panels (at least not freely draggable ones). Though I'm also aware that not everyone using CEGUI is writing a game

Yeah, the project I work on is not a typical game though ultimately it is a game. I use draggable/resizable windows for everything. Like Tiblanc, a lot of my windows are lists, editboxes, graphs, etc. I actually don't have any static-gui windows in my project. The other reason is that I use absolute-values for positioning and sizing (no auto-scaling) and our target audience will have a wide-range of resolutions; larger resolutions will show more scenery and thus allows for larger windows as well. So there will definitely be some dragging/resizing going on, but once in place should not be changed very often.

[Tiblanc]

I did some profiling and found the source of the problem. Seems like it's not in CEGUI, but in Ogre. This bit of code in OgreTextureTarget::declareRenderSize takes about 60ms for 1 call(Debug and Release) and is called whenever I increase the size of the FrameWindow

That wasn't Ogre either. Apparently I forgot to install the latest drivers for my video card when I reinstalled Windows. I get no stuttering anymore! Yay!

And yes, I'm handing over my geek card...

[CrazyEddie]

You should go and stand in the corner and think about what you have done!

I've been playing around with some profiling the last couple of evenings, though did not get the ImageDim to feature prominently anywhere - I looked at the code and it's definitely possible to cache the image there rather than looking it up - once I better get something measurable in relation to this and confirm the change is an improvement I'll commit it

CE.

[Tiblanc]

I've been playing around with some profiling the last couple of evenings, though did not get the ImageDim to feature prominently anywhere - I looked at the code and it's definitely possible to cache the image there rather than looking it up - once I better get something measurable in relation to this and confirm the change is an improvement I'll commit it

Maybe it was because the only thing I was doing was dragging a side of the FrameWindow. I lost my profiling data when switching lib versions and testing them(:(), but from what I remember, it was happening in the MultiColumnList::configureScrollbars function. The getListRenderArea() function gets called 3 times there and that causes a complete recalculation of the sizes, which ended up calling ImageDim and WidgetDim. Drag the corner instead of a side and that gives you 6 calls per mouse move event. The updateThumb() function was also calling them a lot and that came from Window::onSized which called performChildWindowLayout.

Hope that helps!

[CrazyEddie]

Hi,

Thanks for the info; it's very helpful actually

I've been digging around and I now see what you mean about the issue with dragging from the corner where it basically does twice as much work as it needs to - I'll definitely be addressing that one as it's really pretty poor

CE.