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 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
Since real painting is suppressed if the user edits text very fast, this solution should be more efficient than the current one.
Michael
