Hi Petr, Petr Kobalíček wrote: > I try to more describe my point of event handling. For example try any > qooxdoo component (container like, list, table, tree) and press up > arrow. Cpu meter will jump to 100% and stay in 100% usage until you > unpress the key. We observed this behaviour and found out that it's only affecting some setups. My setup (Firefox 3 running on Linux) doesn't show the "100%" issue. Another windows machine also does not show up these values. We've managed to observe this issue on a Mac/Firefox3 (don't blame the Mac ;-) ), so it's seems to be not a "normal" behaviour. Could you please file a bug report, so we can examine this issue in the future?
> I'm just interested what is needed to handle simple keyboard event > that will not generate any action ? Yeah, there are some attached > event handlers in controls, so there is some code executed, but if I > calculate 30 keys per second, the code that is executed must be huge. The key event handler attaches itself to the document and process every keydown/keypress/keyup events and transforms these DOM events into qooxdoo events. The listener to these events are notified and it does rely on the application code which code is executed. Besides this there is framework code involved which does this transformation and the event handling. But you can't easily turn off this logic, since it's a whole key handling "system" which only works completely. But as I already mentioned, the behaviour you described seems to be present on *some* but not all machines (at least my linux box and one windows box here are not affected), so there seems to be not easy out-of-the-box solution. cheers, Alex > > 2008/12/8 Alexander Back <[EMAIL PROTECTED]>: >> Hi Petr, >> >> Petr Kobalíček wrote: >>> Hi all, >>> >>> I have taken a note that keyboard handling in qooxdoo is slow. When I >>> press a key, my 1.6Ghz processor runs at 100% speed even that >>> application is doing nothing. This also happens to mouse moving in >>> browser client area. >> First of all 100% CPU is nothing to worry about at all :) >> When the browser (or any other program) is running and executes several >> commands etc. this is done with the maximum power -> 100% cpu. You have >> to start worrying when this full load is lasting for a longer period. >> >>> I have not problem in 100% cpu usage, but for example moving cursor in >>> table, tree or list is also slow due to this issue. Is there some >>> chance that this will be better in the future or it's caused by >>> universal qooxdoo event handling with no chance to be faster ? >> I've just tested the tree and some other widgets and I did not encounter >> at any time a load of 100% cpu and I personally do not think that the >> root of the load you described is the event handling inside of qooxdoo. >> It would be interesting if you can share some insights with us. What >> do you execute when the selection has changed? Maybe the code executed >> with each change of the selection has some performance issues. Could you >> send over some of your code to look at? > > Maybe your CPU is too fast. If you have notebook, select 'max baterry' > power schema and try qooxdoo. This can help you to see how are user > experiences in slower CPUs:-) I have 3 years old notebook (1.6Ghz > turion) and qooxdoo works well, but if i'm running on battery and CPU > clock is only 800Mhz, qooxdoo is quite slow. > > But, I know that qooxdoo abstracts many things, so this is not > problem:) It's good API :) > >>> I'm also wrote game in javascript (using canvas or dom) and I wanted >>> to reuse my qooxdoo experiences to give it good user interface (and >>> implementation of editor) in qooxdoo, but my discovery was that I >>> can't use it due to speed issues (but this is not qooxdoo fault, I >>> just wanted to use it in area that's not created for). >> What do you use for your game? Full-featured widgets or the low-level >> layer of qooxdoo? > > I wanted to use full featured widgets, game itself is not written in > qooxdoo, I'm using own small library thats optimized for speed. > >>> If there are any tips related to event dispatching speed in qooxdoo I >>> would like to read them. >> In my point of view the dispatching speed is not the problem/the >> bottleneck to look at. It would be interesting what's happening at each >> selection change or that piece of code which is executed as result of >> the key press events. > > Maybe profiling can help me:) > >> cheers, >> Alex ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
