From bug 836565: > An issue here is that when the zoom level changes, we redraw the entire display-port > in a single, un-cancellable transaction - this may cause a bigger delay than is > necessary. > > Instead, we could redraw the visible area and progressively update the area outside > of that afterwards, which ought to provide a faster initial update (assuming that > update time is almost entirely drawing and the page is reasonably uniform, you're > looking at a time reduction of ~75%). Note the comment 'Only draw progressively when > the resolution is unchanged.' in BasicTiledThebesLayer. This is being split out into a separate bug, since it's probably something that we want to to anyway, unrelated to reflow-on-zoom. I'm attaching the patch that was originally attached to bug 836565 and re-requesting review.

Comment on attachment 723958 [details] [diff] [review] progressive-zoom-update Review of attachment 723958 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/basic/BasicTiledThebesLayer.cpp @@ +633,5 @@ > // Store the old valid region, then clear it before painting. > // We clip the old valid region to the visible region, as it only gets > // used to decide stale content (currently valid and previously visible) > + nsIntRegion oldValidRegion; > + // If the resolution has changed, don't retain any old content. // Only retain content if the resolution has not changed. @@ +635,5 @@ > // used to decide stale content (currently valid and previously visible) > + nsIntRegion oldValidRegion; > + // If the resolution has changed, don't retain any old content. > + if (mTiledBuffer.GetFrameResolution() == mPaintData.mResolution) { > + nsIntRegion oldValidRegion = mTiledBuffer.GetValidRegion(); This oldValidRegion is shadowing oldValidRegion on line 636.

This isn't really valid anymore.