The Event objects and Property objects waste many memory in a huge project that include lots of windows. These data should be per class but not per instance!
----------------------------
Sorry for my pool english
Why Event and Property are per instance?
Moderators: CEGUI MVP, CEGUI Team
- thejinchao
- Just popping in
- Posts: 11
- Joined: Tue Aug 23, 2005 08:00
- Location: Beijing. China
- Contact:
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Events can't exist statically, or per-class, since when you subscribe to an event, you're subscribing to the event on that particular instance of the window. If you had a series of buttons, for example, and subscribed a handler for when the button were pushed, if the events were per-class, then all handlers would be called when any button were pushed.
The Property objects are already static, though since the contents of the PropertySet itself is actually composed during object construction, it's final contents are determined by the actual class (and it's super classes) being constructed; this makes things a small bit more complicated (though not prohibitively so). It's also possible that the client app might want to add extra properties to a given instance of a window. Additionally, such custom properties might want to store data directly, which means you'd need one per instance (none of the built-in properties do though, since, as mentioned, they're static).
Having said the above, it is not to say that improvements could not be made in this area (such as Event objects only being instantiated if they have a handler subscribed to them).
I'd be happy to review any patches you submit
CE.
The Property objects are already static, though since the contents of the PropertySet itself is actually composed during object construction, it's final contents are determined by the actual class (and it's super classes) being constructed; this makes things a small bit more complicated (though not prohibitively so). It's also possible that the client app might want to add extra properties to a given instance of a window. Additionally, such custom properties might want to store data directly, which means you'd need one per instance (none of the built-in properties do though, since, as mentioned, they're static).
Having said the above, it is not to say that improvements could not be made in this area (such as Event objects only being instantiated if they have a handler subscribed to them).
I'd be happy to review any patches you submit
CE.
- thejinchao
- Just popping in
- Posts: 11
- Joined: Tue Aug 23, 2005 08:00
- Location: Beijing. China
- Contact:
Thanks for explain
I'm working for a MMORPG project. The UI part is so complex (lots of texture and lots of windows) . I am trying to decrease the memory used by CEGUI and startup time lately.
I plan to move event and property objects to WindowFactory class. Thanks for your explain . I will think careful about it.
----------------------------
Sorry for my pool english
I plan to move event and property objects to WindowFactory class. Thanks for your explain . I will think careful about it.
----------------------------
Sorry for my pool english
- thejinchao
- Just popping in
- Posts: 11
- Joined: Tue Aug 23, 2005 08:00
- Location: Beijing. China
- Contact:
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Heh, you noticed this then
I decided that 99% of the events on any given Window were never actually getting used, and that this truly was wasteful; we'd already proven the idea of dynamically added events in the GlobalEventSet, so extended this idea to all EventSet based objects.
Another bonus is that it could potentially help performance a little too, since lookups may be shorter, and there is now no firing of unsubscribed, or "empty", events
CE.
I decided that 99% of the events on any given Window were never actually getting used, and that this truly was wasteful; we'd already proven the idea of dynamically added events in the GlobalEventSet, so extended this idea to all EventSet based objects.
Another bonus is that it could potentially help performance a little too, since lookups may be shorter, and there is now no firing of unsubscribed, or "empty", events
CE.
GUCEF event system
Eddie maybe you can draw some inspiration from my event system in GUCEF:
http://www.vanvelzensoftware.com/phpBB2 ... c.php?t=25
The event classes are in the gucefCORE library. The main classes are CObserver, CNotifier, CEvent and the rest are derivatives for more complex scenarios.
I use events definitions per class with subscriptions per instance per event. Events are registered as strings but have a unique auto generated numeric ID which I use for comparison versus string comparisons.
Even if you don't like it I'd love to hear your thoughts on it.
http://www.vanvelzensoftware.com/phpBB2 ... c.php?t=25
The event classes are in the gucefCORE library. The main classes are CObserver, CNotifier, CEvent and the rest are derivatives for more complex scenarios.
I use events definitions per class with subscriptions per instance per event. Events are registered as strings but have a unique auto generated numeric ID which I use for comparison versus string comparisons.
Even if you don't like it I'd love to hear your thoughts on it.
Last edited by Liberator on Mon May 19, 2008 15:47, edited 1 time in total.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Return to “CEGUI Library Development Discussion”
Who is online
Users browsing this forum: Google [Bot] and 6 guests