[SOLVED]Resizing a FrameWindow causes slowdowns

[Tiblanc]

Hi all!

I'm using CEGUI 0.7 with Ogre. The problem I'm seeing is when I resize a FrameWindow, it causes massive slowdowns when the size increases. The FrameWindow contains 1 MultiColumnList and 3 Buttons. I can mess around with the size and it will be fine as long as it's kept under the original size. As soon as I try to increase its size, the slowdown occurs. I'm new to CEGUI so I don't really know what's going on yet, but I'm guessing this has to do with texture reallocation? I glanced over the logs and don't see any error. The issue remains in debug and release builds. I tried searching the forums but came with nothing. Is this a known issue? Is there anything I can do to fix it?

Here's my layout file :

Code: Select all

<?xml version="1.0" ?>
<!-- Layout file for squad list window -->
<GUILayout>
<Window Type="DefaultGUISheet" Name="SquadListWindow">
    <Property Name="MousePassThroughEnabled" Value="true" />

    <Window Type="TaharezLook/FrameWindow" Name="SquadList">
        <Property Name="UnifiedMaxSize" Value="{{1,0},{1,0}}" />
        <Property Name="UnifiedSize" Value="{{0,610},{0,400}}"  />
        <Property Name="Text" Value="Squads" />

        <Window Type="TaharezLook/MultiColumnList" Name="SquadList/List">
            <Property Name="UnifiedPosition" Value="{{0,5},{0,5}}"  />
            <Property Name="UnifiedMaxSize" Value="{{1,0},{1,0}}" />
            <Property Name="UnifiedSize" Value="{{1,-20},{1,-45}}"  />
            <Property Name="ColumnHeader" Value="text:Name width:{0.4,0} id:0" />
            <Property Name="ColumnHeader" Value="text:Status width:{0.6,0} id:1" />
        </Window>
       
        <Window Type="TaharezLook/Button" Name="SquadList/CloseBtn">
            <Property Name="UnifiedPosition" Value="{{1,-105},{1,-32}}"  />
            <Property Name="UnifiedMaxSize" Value="{{1,0},{1,0}}" />
            <Property Name="UnifiedSize" Value="{{0,100},{0,30}}"  />
            <Property Name="Text" Value="Close" />
        </Window>

        <Window Type="TaharezLook/Button" Name="SquadList/ViewBtn">
            <Property Name="UnifiedPosition" Value="{{1,-210},{1,-32}}"  />
            <Property Name="UnifiedMaxSize" Value="{{1,0},{1,0}}" />
            <Property Name="UnifiedSize" Value="{{0,100},{0,30}}"  />
            <Property Name="Text" Value="View" />
        </Window>
       
        <Window Type="TaharezLook/Button" Name="SquadList/NewBtn">
            <Property Name="UnifiedPosition" Value="{{1,-315},{1,-32}}"  />
            <Property Name="UnifiedMaxSize" Value="{{1,0},{1,0}}" />
            <Property Name="UnifiedSize" Value="{{0,100},{0,30}}"  />
            <Property Name="Text" Value="New" />
        </Window>
       
    </Window>

</Window>

</GUILayout>


Thanks!

[fedyakin]

Since I'm using Ogre (1.6.1) and cegui 0.7, I figured I would try out your layout file and see if I experienced the same problems. Even in debug build, I saw no noticeable effect on frame rate while resizing the window.

If the drop in framerate is large enough, you could try breaking in the debugger while this is happening and see whats on the callstack. Doing that might turn up something useful. Alternatively you could try http://developer.amd.com/CPU/CODEANALYS ... fault.aspx to see if there is an obvious culprit.

sorry I can't be of more use...

[CrazyEddie]

Hi,

While I did not test the layout myself yet (may do later, after I've knocked of a bunch of jobs from yesterday), it is plausible that the texture re-allocation causes performance hits - this normally manifests more as a 'stutter' rather than a 'slow down' though perhaps it's the same thing! If you think you are affected in this way, you can probably minimise the effect by setting the size of the window to the maximum you intend (to allocate the larger texture) then re-set the size to the desired initial size.

Two points come to mind as I type this:
1) It may be useful for us to add a setting that can pre-allocate a larger texture size upon the users request.
2) There may be a bug in the current code as regards to checking texture sizes and deciding when/if to reallocate (I only mention it because I fixed a similar issue with Irrlicht last night).

HTH

CE.

[Tiblanc]

Thanks for the replies!

@CE
It is more like a stutter like you said. I'll try to figure out the culprit this weekend and see what I can find.

@fedyakin
Are you using OpenGL or DirectX renderer? I'm using OpenGL so this may be the difference.

[CrazyEddie]

Also note that, aside from the texture generation, resizing is still one of the activities that may cause performance drop - especially if all the window content is relatively scaled, since it triggers a major recalculation of everything on the window - there's nothing we can do about this, since if the content has to be updated, it has to be updated The only other thing I'm currently aware of that can have a large impact is if you were to modify the alpha of an entire layout - the reason for this is the same - it causes a full regeneration of affected content (there are a couple of optimisations we can look into for this particular case, and that will probably be done for one of the later 0.7.x point releases).

CE.

[fedyakin]

I was using Direct3d; I tried it with the OpenGL renderer and it still ran fine for me. This machine has a fairly high-end video card though...

[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

Code: Select all

    Ogre::TexturePtr rttTex = Ogre::TextureManager::getSingleton().createManual(
        OgreTexture::getUniqueName(),
        Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME,
        Ogre::TEX_TYPE_2D, sz.d_width, sz.d_height, 1, 0, Ogre::PF_A8R8G8B8,
        Ogre::TU_RENDERTARGET);


I find it odd since I got a core 2 duo 6400 and a GeForce 7900GS, which is still decent enough these days I guess. Could be some driver issue. I'll mess around a bit.

@Fedyakin
Are you using the Ogre SDK from their site or did you use some version from their SVN? Also, are you running Windowed or Fullscreen? I'm in Windowed mode, although I doubt this has an impact.

On a related note, I found some places where major optimisations could be done. MultiColumnList::onSized is fairly slow at close to 5ms per call and could cause some frame skips when the FrameWindow is resized. Seems to boil down to a lot of calls to getValue_impl. WidgetDim::getValue_impl is a pretty bad offender in my case. This bit of code

Code: Select all

wnd.getName() + d_widgetName;

can take 150us per call in some situations and seems to be done when WidgetDim::getValue_impl is called(it's in a if statement). Since it's called a lot whenever the FrameWindow is resized, this can easily add up to a few milliseconds. Maybe this could be cached?

Also, ImageDim::getValue_impl is a bit faster(1/4 of the time), but is called 4 times more.

Code: Select all

const Image* img = &ImagesetManager::getSingleton().get(d_imageset).getImage(d_image);

This line takes all the time. Time is split about 35%/65% between get() and getImage(). Would caching the Image be practical? I doubt the image object changes all that often.

So the time spent recalculating everything on the window seems to be caused by a String concatenation and getting an Image object and not really about updating everything GUI related.

[CrazyEddie]

Hi,

I think we might expect texture creation to be somewhat expensive, although

declareRenderSize ... is called whenever I increase the size of the FrameWindow

definitely sounds like we have the same bug from Irrlicht in the Ogre renderer also - I will check and address this, as if it is doing this (and it sounds like it is) then that's definitely not what was intended.

In regards to your profiling analysis, I can confirm that this corresponds somewhat to things I have seen myself[1]. For WidgetDim::getValue_impl caching the final string (or even the final value) is currently very difficult at the moment - only one instance of those skin related objects exist and are potentially applied to multiple windows, so wnd.getName() can return a different name at any time - however - there obviously are ways we can cache these values, though we need some new mechanism to deal with this (so it's something I'll look into, but it's not a quick-fix item, as it will need thorough testing ). The situation with image lookups is somewhat different, and I believe that in many (most?) cases caching of the image will be possible - I'll look into this, perhaps as early as this afternoon.

Depending upon progress on other items, I may get some of these things looked at today, or almost certainly tomorrow. Why all the haste? Well I want 0.7.1 to have as many fixes from 0.7.0 as possible, and to get that release out as soon as possible, so currently I'm all about responding and fixing these issues and other concerns as they come in (or near enough).

CE.

[1] Basically there's a lot of time spent in string operations and object lookups. This was seen in post modification runs done after the renderer rewrites, so while it certainly piqued my interest, at that stage I was mainly checking that the base level rendering objects were performing better than the components they had replaced. The rationale being that while it was clear that other issues existed, the impact of those issues would be no worse than before (kind of like a case of just having 'bubbled up' perhaps due to other items having less of an impact).

[Tiblanc]

Ah yes I figured it couldn't be that simple

I think we might expect texture creation to be somewhat expensive, although

declareRenderSize ... is called whenever I increase the size of the FrameWindow

definitely sounds like we have the same bug from Irrlicht in the Ogre renderer also - I will check and address this, as if it is doing this (and it sounds like it is) then that's definitely not what was intended.

From what I saw, while it's called whenever the window is resized, the texture is only reallocated when the size increases. If I resize it under it's original size, the framerate will drop a bit, but is not as bad as when I increase the size, at which point the whole thing stutters. Anyways, that problem seems to be on Ogre's side so I'll be checking over there for some hints.

Thanks!

[CrazyEddie]

The behaviour of this, is supposed to be as follows:

Create window at say 200 x 200 (call to make new texture)
Make window smaller to 100 x 100 (no call to make new textre)
Make window larger to 400 x 400 (call to make new texture)
Make window smaller to 200 x 200 (no call to make new texture)
Make window larger to 300 x 300 (no call to make new texture)

The key here is that last one - since the texture we have is already 400x there is no need to create a new texture under this condition, however from your description it seems that we are calling to make a new texture. I'm going to check our handling of this under Ogre today.

Btw, in regards to significant slow-down when sizing a FrameWindow with various content, I only get really bad results when running a MSVC++ debug build. For example when I was testing the MCL issue, under this config resizing the containing FrameWindow would take me from ~1300 FPS to ~180 FPS - in all other cases the drop was much less significant.

CE.

[Tiblanc]

The behaviour of this, is supposed to be as follows:

Create window at say 200 x 200 (call to make new texture)
Make window smaller to 100 x 100 (no call to make new textre)
Make window larger to 400 x 400 (call to make new texture)
Make window smaller to 200 x 200 (no call to make new texture)
Make window larger to 300 x 300 (no call to make new texture)

The key here is that last one - since the texture we have is already 400x there is no need to create a new texture under this condition, however from your description it seems that we are calling to make a new texture. I'm going to check our handling of this under Ogre today.

Sorry, I must have poorly worded the issue. The slowdown does not occur at that last step.

I noticed something while retesting it though. When I drag the corner, it seems like it recreates the texture twice. Once for the right side and once for the bottom side. Same thing with that slowdown even if size does not exceed historical maximum(that should be clearer ), it's a bit slower when dragging corner vs side. These could probably be combined since it's essentially doing for work twice for nothing.

[CrazyEddie]

Right. Well that behaviour is correct then

I think what we should be doing, and what my original test / proof app did, is create - or have an option to create - textures larger than what's needed immediately. The situation at the moment is that every time the window grows by one pixel, that's another reallocation. If we stepped this a little - 64 or 128 pixels, or something - this would reduce the reallocations by quite a bit I think. What do you think?

I've been looking at the other perf issues a bit this evening... Nothing of any use to report at the moment

CE.

[Jamarr]

Pre-allocating larger textures may be preferred to the current implementation, but this is ultimately going to increase ram useage unnecessarily and possibly slow down the entire app if ram is limited. And so long as the app allows resizing it is impossible to know what size window the user will ultimately want. To me this sounds more like a temporary workaround than an actual solution.

Instead, I think it would be more efficient to switch to an immediate-mode RenderTarget during sizing (add EventSizingStarted -> EventSizingEnded events if not already), and once resizing has ended switch back to the original RenderTarget and then generate the new texture.

It may even be beneficial to always cache the new window size, instead of only caching the largest size. If nothing else this should be an option for cases where ram is limited. It could even imporove performance over the current implementation, at least in apps with significant ram useage since the graphics card would have more ram available for other things; imo resizing a window isn't something that happens often enough to warrant storing a larger texture than is necessary. And if the window is being resized that much, you should be using an immediate-mode RenderTarget anyway.

[CrazyEddie]

Yeah, this is one of those situations where there is no one size fits all solution, and largely I agree with what you say.

The idea about disabling the texture target usage during sizing is definitely something that could be considered (on the app side, I mean) and as such I'll add those events - since we do not have them currently.

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.

It would be good to get a lot more feedback on this whole concept and how people view the situation before I start making any large changes in this area.

CE.

[Tiblanc]

The main reason why I want resizable windows is because the UI will mostly be a lot of lists so the option to see more or less rows is a plus. A bit of slowdown once to resize the window is not a game-stopper in any case. It just struck me as odd, which is why I posted about it.

Doing a larger allocation would certainly help. If I start resizing a window, it will generally last a few frames, so preallocating a larger texture would save a few reallocations almost everytime.