CEGUI (Crazy Eddie's GUI) Forums

Hi
we are migrating our application from cegui 6.2 to 7.1.
I have noticed a terrible perf on the 7.1 platform.
I suspect i m missing opengl drivers, did anyone notice the same perf degradation ?
i will see if i can find "up-to-date" opengl drivers but if team could confirm why an upgrade may be needed would be nice,
thanks

(note : if probleme is really drivers and if there is a way of compiling the cegui 7.1 to not have those perf issue it would be great as i think i cannot update my laptop display driver )

PLEASE POST THE CEGUI.LOG FILE Every time somebody asks machine and build dependent questions and do not post the log, you immediately put me on the offensive. I am the dynamite monkey; do not taunt me

Additionally, you don't quantify the results you're seeing, or tell us any information about what kind of windows and such you have created, or the hardware that you're running on. So it's hard to even know what you consider "terrible", much less start to formulate some way we might be able to reproduce any issues and diagnose problems. Are you able to test on multiple systems with different hardware configurations? Do all configurations exhibit the issue, or just some, or one?

As far as performance overall, there has been one other user (Armitage1982) who has experienced a decrease in performance as compared to 0.6.x, however we were not able to ultimately determine why (the best we concluded is that it might be some way hardware related, but even that did not really 'add up'). For my part, all I can report is the results of tests on the hardware that I myself own, and on all systems I tested I saw increased performance when comparing the 0.6.x releases to the 0.7.x releases.

As regards to why a driver update may be needed, well, that's another though one. Drivers get broken, fixed, tuned and retuned all the time - so things that work fine in release 'A' may not work right in release 'B', get fixed in release 'C' and so on - and all of this is obviously out of our hands We are doing more / different stuff than we used to (such as rendering to texture), but still nothing earth shattering (for example, it still runs on my crappy 10+ year old laptop - not fast, by any means, but still improved over the 0.6.x code). But still it's possible that these new techniques affect something and needs a driver update, I guess.

CE.

Hello
yes right ;...

ok i will provide logs, meanwhile i m answering what i can:

i am using a IBM think pad with ATI Mobility Radeon 7500, driver 8.030 something like this, 1.7h Ghz (intel) 1 gig ram.

as for what i am displaying its kind of complex, there are lot of stuff, from tabbed windows to multicolumn list, 2d scene , tree view etc, a lot of custom widget actualy.

i can see the issue but another pc (i dont know the hardware) is not. will try on a third system.

I can try to remove sme windows and see where it could start beeing slow,

another point is that using release build of cegui it just freeze, even before displayng the first window.

maybe its a bug in migration , it is possible, i will investigate more and come back on this,

another point is that using release build of cegui it just freeze, even before displayng the first window.

This interests me for a couple of reasons.

First it implies that you're using debug builds (since release will not run), the fact is - assuming MSVC++ - that debug builds are inherently slow, sometimes to the point of being near unusable; this is not 'us' as such, but the amount of extra work and checks done by a regular debug build - it may be that you'll need to come up with a 'custom' debug build that does not exhibit all of the issues (basically here you need to consider what you want from a 'debug' build - I'm guessing to debug your app, and not to debug CEGUI itself, therefore it may be possible to compile a 'debug' build of CEGUI in such a way that most of the checks are disabled. All you're really after is to ensure that the debug c/c++ runtime is used. All this being said, I've not done this kind of thing for a long, long time, since it's no longer the platform I use for development).

Second, I wonder whether you're using an SDK or built CEGUI yourself. The original 0.7.1 SDKs had a fubar'ed release build - we have fixed versions now (as of yesterday). If you're building yourself, you need to ensure you're not getting bitten by the same issue (basically, avoid the ReleaseWithSymbols build for now - we have a fix, but it involves a customised premake binary).

CE.

Thanks !

in fact i could not post before because forum was down, but i think i understand whats going on (for the perf issue).
In fact there is no issue. The explanation may be this:
1. when i built with 6.2 cegui i was using vc 2003 sdk.
2. now i am using vc2008.
(in both i am compiling cegui debug mode)

so its not a matter of perf changes between 6.2 and 7.1 but between stl debug in 2003 sdk and 2008: in 2003 there is noextensive "iterator debug", but since vc2005 they have added this iterator debug stuff. I profiled my application (using 7,1 cegui) and noticed that most of the cpu is eaten in the stl (_Orphan_me).

so i could not test rebuilding the debug version of cegui 7.1 with the -Dhas_iterator_debugging=0 flag but i guess it will fix my issue.

i am planning to test release version as well (which does not have this iterarator debugging stuffo ON) but as i said i had issue, but its my fault i m mixing dllmultithread with dlldebug multithread libs.

so so far so good i would say i will post to confirm (or not ) this

Hi,

i could not post before because forum was down

Yeah, we've has some, err... issues

Thanks for posting the information you have so far; it's very helpful and informative. We do make somewhat extensive use of STL containers and iterators, so if these additional debug checks cause those to slow down, it would certainly explain the impact on CEGUI while those checks are active.

CE.

ok just to confirm that setting:
_HAS_ITERATOR_DEBUGGING=0;
_SECURE_SCL=0

in debug ceguibase_d.dll build conf fix the perf issue.
as for the release build its even faster.

Cool. I think us adding a premake option in config.lua to set these would be a really useful addition

CE.