On Sun, May 08, 2005 at 12:05:50PM +0200, Michael Schmitt wrote: > Asger Ottar Alstrup wrote: > > >A better fix is to go to the root of the cause, and in this case, as > >mentioned in another post, I believe the right fix is to either omit > >or postpone the qApps->processEvent calls during update. > > > >Of course, excessive update calls from other places, as found by > >George, should also be nailed. (Notice, that the optimisation as > >sketched out would reduce the cost of superfluous update calls to a > >metrics and null-paint job only - the outcome would be identical to > >before, and no painting on screen would be necessary). > > So the "best" solution would be: > > 1. Run metrics computation & null painter as a single
This is conceptually impossible. If using the nullpainter turns out to be cheap, we could have a three-phase update (metrics + nullpainter + painter) and safely skip the third phase when needed (i.e. the next update is already pending). > non-interruptable, non-reentrant step > (There should be some assertions in the code that check that update > isn't executed twice simultaneously; this should be easily doable by the > introduction of a static variable that is incremented when entering > update and decrement when leaving update) > 2. At the end of metrics computation & null painter, check whether > there is a new event > 3a. If yes, process the event, skip real painting > 3b. If no, go on with real painting The rest is ok. In any case this will be quite some reorganzition of all current inset drawing code and I think we should try to remove the processEvent calls first. > Since real painting is suppressed if the user edits text very fast, this > solution should be more efficient than the current one. I some situations yes. In some (when the user types slowly or the machine is fast enouhg), not. Andre'
