Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

wxUpdateUIEvent performance issues

<< < (2/2)

dmoore:

--- Quote from: thomas on December 11, 2009, 07:58:17 pm ---Hmm... this brings up another thing. I've noticed that Code::Blocks really sucks dick if you run it via XDMCP (even on a 1Gbps network with a single Netgear router in between and roughly 4 meters of total cable length).
It takes upwards of half a second (usually more) before Code::Blocks registers a mouse click or opens a menu. I've always wondered why XDMCP performance is so abysmal, especially since other programs run as if they were started locally.

Now, gears in my head start moving... what if this infrequent event polling in combination with the network latency (probably 1ms or less, but still...) is what screws it all up?

--- End quote ---

just moving the mouse around a bit can generate hundreds of update ui events. (i.e. the 100ms UpdateInterval doesn't really stop the events, perhaps just delays them). that might do it?

Jenna:
One thing to reduce the amount of calls to the event-functions is to bind only one ID to the appropriate OnxxxMenuUpdateUI-function.
It should be an ID that is used by the menu and the toolbar.
I tested with idFileSave, idFileSaveProject (only needed for the Project menu, not a toolbar), idEditUndo, idSearchFind and idViewToolMain (just for the View-menu).
All other bindings are redundant, because they do the exactly same thing and do nothing but create unnecessary overhead.
The same can be done for the compiler- and debugger-plugin (idMenuCompile and XRCID("idDebuggerMenuDebug")).
All other bindings can be commented out, without changing the behaviour (of course only the EVT_UPDATE_UI-macros should be commented out).
Setting the update-interval to 500 ms reduces the overhead some more, without slowing down update too much, at least for me.

Please test (if you find the time) and post your experience with it.

Navigation

[0] Message Index

[*] Previous page