DestroyWindow strange behavior

For help with anything that CEGUI doesn't offer straight out-of-the-box, e.g.:
- Implementation of new features, such as new Core classes, widgets, WindowRenderers, etc. ...
- Modification of any existing features for specific purposes
- Integration of CEGUI in new engines or frameworks and writing of new plugins (Renderer, Parser, ...) or modules

Moderators: CEGUI MVP, CEGUI Team

User avatar
daesdemon
Quite a regular
Quite a regular
Posts: 60
Joined: Fri Mar 11, 2005 21:19
Contact:

DestroyWindow strange behavior

Postby daesdemon » Wed Apr 20, 2005 12:39

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?

User avatar
lindquist
CEGUI Team (Retired)
Posts: 770
Joined: Mon Jan 24, 2005 21:20
Location: Copenhagen, Denmark

Re: DestroyWindow strange behavior

Postby lindquist » Wed Apr 20, 2005 17:05

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();
}

User avatar
daesdemon
Quite a regular
Quite a regular
Posts: 60
Joined: Fri Mar 11, 2005 21:19
Contact:

Re: DestroyWindow strange behavior

Postby daesdemon » Wed Apr 20, 2005 18:30

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??

User avatar
lindquist
CEGUI Team (Retired)
Posts: 770
Joined: Mon Jan 24, 2005 21:20
Location: Copenhagen, Denmark

Re: DestroyWindow strange behavior

Postby lindquist » Thu Apr 21, 2005 14:01

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.

User avatar
daesdemon
Quite a regular
Quite a regular
Posts: 60
Joined: Fri Mar 11, 2005 21:19
Contact:

Re: DestroyWindow strange behavior

Postby daesdemon » Thu Apr 21, 2005 14:41

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 :D :D

...hope your finger is not too painful ;)

User avatar
lindquist
CEGUI Team (Retired)
Posts: 770
Joined: Mon Jan 24, 2005 21:20
Location: Copenhagen, Denmark

Re: DestroyWindow strange behavior

Postby lindquist » Thu Apr 21, 2005 14:58

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

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

User avatar
daesdemon
Quite a regular
Quite a regular
Posts: 60
Joined: Fri Mar 11, 2005 21:19
Contact:

Re: DestroyWindow strange behavior

Postby daesdemon » Thu Apr 21, 2005 15:13

No , they are created dynamicaly :(

User avatar
gcarlton
Just can't stay away
Just can't stay away
Posts: 149
Joined: Wed Jan 12, 2005 12:06

Re: DestroyWindow strange behavior

Postby gcarlton » Fri Apr 22, 2005 02:48

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. :?

User avatar
daesdemon
Quite a regular
Quite a regular
Posts: 60
Joined: Fri Mar 11, 2005 21:19
Contact:

Re: DestroyWindow strange behavior

Postby daesdemon » Fri Apr 22, 2005 10:55

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. :evil:

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.


Return to “Modifications / Integrations / Customisations”

Who is online

Users browsing this forum: Google [Bot] and 5 guests