[WebODF] Performance again - event queue

[Tobias Hintze]

Hi,

I just read a mail from some time ago which I seem to have missed
before on this ML. It's from 2013-08-06:
 '[WebODF] 2 month performance blitz for webodf'.

There is one thing I would like to add to the specific example
of terrible performance of our yet unoptimized code in this regard.
Philip gave the example of 500ms delay for deleting a single
character. That is of course bad - but it is even worse:
What does the Average Joe do to delete 5 words? Right! He would
press AND HOLD the delete key and stops when the words are gone.

Ever tried that in the 500ms scenario? The problem is that the
key event is processed immediately and the browser is busy for
the 500ms, and when the browser comes back from being so busy,
there will be like 100 more key events queued. The problem is
obvious: the browser will be busy again for 500ms x 100 times,
without any time in between for anything else.
In my opinion we need to separate the event-reading from the
event-processing. The event processing needs to happen in a 
way which gives the browser a small time slot to take care of
its other duties as well. So my proposal is to read the key-event;
perhaps also create the resultant Op from it, but then just
enqueue the Op for execution. Then we have a chance to do sane
scheduling of Op execution and making sure the browser does not
starve by giving it small time slots for survival.
The effect is that the browser does not appear locked for
a long period to the user, but instead the users will see one
execution rendered before the next one starts.

We had a similar effect when playing long lists of Ops. Changing
this to "chunked" Op-replay improved things.

PS: I am aware that the scheduling would not prevent the queue
to fill with 100 key-events while the browser is busy in 
execution. But it will change the user perception from 
"browser dead - webodf crashed" - to "it is a bit slow down here".

th
-- 
Tobias Hintze // KO GmbH
http://kogmbh.com/legal/