DestroyWindow strange behavior

[daesdemon]

Hello,

I have a button whose behavior is to create or delete a frame window with close button enabled, like that:

Code: Select all

bool onButtonPressed(const EventArg&e)
{
    if (!WindowManager::getSingletonPtr()->isWindowPresent(windowName))
    {
        // Create Window
    }
}


Here is the code of the Subscriber of Window closeButton pressed:

Code: Select all

bool onCloseButtonPressed(const EventArg& e)
{
    const WindowEventArg& we = static_cast<const WindowEventArg&>(e);
    destroyWindow(we.window);
}


The problem is everything work quick the first time i create the window, but the next times, it takes more more time to create it.
Why? How can i make thing work better?

[lindquist]

only create the window the first time.
and then just toggle visibility afterwards...

Code: Select all

bool onButtonPressed(const EventArg&e)
{
    if (!WindowManager::getSingletonPtr()->isWindowPresent(windowName))
    {
        // Create Window
    }
    else
    {
        WindowManager::getSingleton().getWindow(windowName)->show();
    }
}


Code: Select all

bool onCloseButtonPressed(const EventArg& e)
{
    const WindowEventArg& we = static_cast<const WindowEventArg&>(e);
    we.window->hide();
}


[daesdemon]

Thx lindquist, that's nice , but it doesn't explain why the second and after creations are so long.

I have think about just show and hide, but the problem is that i have lots of objects i can edit or i will be able to edit , so i am not sure that keeping in memory all theses windows is a so good idea

For example imagine i have a list a hundred objects , each time i click on the list , it create an Edit Window for this object.
So i can edit multiple object at the same time, you see?

But technicaly, i don't understand this behavior, have you already observe same kind of problem?

No rapport with this Dead Pool , i heard about??

[lindquist]

hi again.

I did a little test to try it out for myself.
I was not able to reproduce your window creating delays.

I just kept getting 1ms pr. window creation. even after a few hundred.

then I just did'nt want to click that button anymore.

regarding the dead pool, I'm not exactly sure what it is that you are asking, but without it none of this would work at all.

my conclusion is that its something you're doing thats causing the increasing delays, but I'll have to have some more details about what it is to be able say anything constructive.

[daesdemon]

Thx linsquist for your clue
I have tested to check with the Ogre Gui Example which take a layout and load it.

I get the same behavior.

I launch the Demo_Gui.exe
I just click Load Test Layout, new and LoadTestLayout a second time, and it begins to block completly the application( mouse blocked).
It is not very visible from the default Layout, but i modify it, adding a frame window with 5 checkboxs, 5 editboxs, 5 comboboxs, and 5 buttons, and i get almost one second blocked.

Exactly the same than my application which have a relativly complex interface too.

PS:
I was thinking of the deadpool as a pool with dead windows, and perhaps, keeping some traces about them.
So perhaps, ressurect them from deadpool could have been more long than creating them from scratch

...hope your finger is not too painful

[lindquist]

are you also creating your frame window from a XML layout ?

edit: if so maybe you should try out the tinyxml loader instead.

[daesdemon]

No , they are created dynamicaly

[gcarlton]

You should triple check to make sure you aren't accumulating windows. The window manager will slow down (slightly) the more windows there are, because its doing multiple finds.

1.) isWindowPresent searches the set
2.) if found, getWindow will then re-search the set
3.) if !found, createWindow will then re-search the set

Hard to see this is causing you major problems, but if you're accidentally leaking windows it is possible. Or it could be something else.

[daesdemon]

Thx gcarlton, but as i says before it is not particular to my application.

With the Ogre Gui Example, with a layout little more complex than the example one, i get one second delay, just by asking for "Load TestLayout" two times. So i don't think i will continue checking my program anymore

Next step is for me to have a look in the creation and destruction code of CEGUI to see what happens that could take that time.

PS: As the window to edit my object take the name of my object, it is not possible i think that i loose some of the windows because, in this case, i should not be able to create them again, since they would have the same name.