Community
Participate
Working Groups
The UI becomme more and more cluttered with tooltips, animations, styled text and so on. A simple mouse hovering consumed lot of cpu time, without even showing tooltips, showed huge amount of events and processing. The swt event dispatch loop should be optimized to execute faster. If not, coalescable mouse events, like mouse moves, should be coalesced to eliminate wasted processing. (It simply requires a insert-ordered map in which we put events, but by a "type" key that allows to clobber the event with the latest value). This may save up to 95% of the eventloop processing on busy UI. profiler snapshot in attachment. The testcase was a simple mouse hover on a java editor.
Created attachment 7742 [details] profiler snapshot
SN will be looking at performance issues.
Please submit your patches that show the speed up. Thanks.
Hum. If you have a month to show me how to build and hack the eclipse core, I may be able to give you a patch ;) For the mean time, I'm giving you a technique that was successfull in my past experiences and designs. I can give more details, if you want but it will remain theory until somebody else than me makes a prototype for eclipse awt event processing. The safest optimization is to coalesce only successive unprocessed events of same types. I would only coalesce mouse drags and mouve moves. I presume you understand that it requires intercepting all mouse events, do coalescing if any and finally forwarding them. That could be done only per components, the editors being a very good example. The actual effect is to strip mouve move/drag event from the event queue, so that it doesn't trig processing. If the consumer processing is always very responsive (too responsive*) the coalescing would never occur. If the consumer chokes, it will benefit from useless events being removed on the procuder enqueue. I wrote "too responsive" because if the ui gets the CPU, it doesn't mean that the CPU has nothing else to do. May the consumer thread is just of higher priority and just moving the mouse over an editor sucks up the CPU power. I would slowdown the consumer thread by emulate a very short latency (few dozen ms) the user wouldn't feel, but choked enough so that we can provoque coalescing and basically code a somewhat constant event processing rate. (Sometimes I feel that tricks like this have already been tried, but I feel the need to make sure you considered it.) Thanks.
The operating systems themselves collapse mouse move events and there is no chance that we would ever try to play with the operating system event queue in this manner.
