Bueno, por lo que se ve "en todos los lados cuecen habas", y no sólo en Microsoft como se suele comentar. El caso es que un programador llamado Vladimir Vukicevic, un programador de FireFox, ha descubierto que Apple utiliza funciones no docu…

I think that this is what “roc’s Compositor design” will add to Firefox, but information is scarce.

Right now Fx works like this:

1) WHILE moreToDo
2) doIt()
3) repaint()
4) END WHILE

But that is wrong. Repaint could “hang” because it’s waiting for a screen refresh. Correct would be

1) WHILE moreToDo
2) WHILE notRepaintNecessary AND moreToDo
3) doIt();
4) END WHILE
5) repaint();
6) END WHILE

That way you would only repaint if it makes sense to repaint and the fact that the maximum number of repaints a second is limited does not limit the execution speed of doIt().

If I understand you right, the test in question is: I run a for loop, that scrolls the page down by one pixel each time. Now each time it scrolls, you issue a repaint, wait for the repaint to complete and then continue the loop. Since these repaints can’t complete faster than the refresh rate (by default, without using the hack you are currently using), the loop now runs slower. Correct? If yes, then this is broken by design. The whole repainting should by asynchron, which is a hundred times better fix than the one you found.

Case A
The for loop should not wait for the repaint to actually happen, it should just request to scroll one pixel and then request the repaint and continue immediately, even if the repaint did not happen. Then it should again request to scroll one pixel and request a repaint - however, this request is ignored, because a repaint is already requested. So far nothing has been re-painted and twice scrolling one pixel should be requested. The third time the loop runs it’s like the second time and so on and so on. Maybe the 8th time the loop is running, the repaint is finally taking place. Now the repaint will repaint once and will immediately scroll the page by 8 pixels. And the whole game starts again.

Case B
Right now you are scrolling one line and repaiting, one line and repaiting, one line and repainting and none of these repaints are ever shown on screen. After the 8th time you are scrolling and repainting, the screen refresh takes place and this repaint is finally visibly.

Both, Case A and B will have a repaint that scrolled by 8th pixels shown on the screen as first image after the loop started. But in Case A, only one repaint was done. In Case B, 7 were done that never showed up anywhere and the 8th one is now visible. Case A is thus plenty of times more effective than Case B.