<is a big document (~882KB).
Loading it in SeaMonkey 1.0, Firefox "Minefield" ("latest-trunk" and
"reflow-refactor" builds) and 9 on Windows, then trying to
resize the window horizontally seems to take quite some time and the
whole action somewhat choppy. Loading it in Internet Explorer 6 if
the scroll position is somewhere at the top of the document, the
resizing is quite instant, but becomes more choppy the more I scroll
down the document (I guess it is because the document is reflowed
from the top, down to the visible area, and the rest of the work is
taken in background, as I could see the scrollbar "flashing" for a
moment after).
Now I experiment with Amaya <http://www.w3.org/Amaya/- the current
9.51 version, and I see loading the same document and resizing the
window has pretty constant satisfactory performance no matter the
document scroll position. The Amaya rendering engine is far from
perfect but I've wondered what could be making it more responsible
in this case? What I notice in the Amaya case is it tries to keep
the scroll position to the top visible block element (in the
viewport) when resizing the window - could it be it reflows as much
as it needs to be visible at the moment and then reflows the rest in
background (in both directions: from the start, up to the first
visible block and after the last visible block to the end)?
I've made my Amaya test using the GL acceleration turned on [1],
but I've tried the overall performance is the same with it turned
off. I realize Gecko takes care of much more than normal flow blocks
but wondered if it could be improved in this regard.
[1]