On 8/8/2012 7:41 PM, Matt Woodrow wrote:
In preparation for relanding DLBI (display-list based invalidation - Bug
539356), I'm going to be landing a set of patches to change the timing of our
painting.
These move painting to be driven by the refresh driver, instead of the OS
widget's paint event. This is a required change for DLBI, and preferable for
off-main-thread compositing (OMTC).
Are there details on what this actually means? e.g. don't we *have* to
paint when when we receive a WM_PAINT event, and usually we shouldn't at
other times?
Unfortunately it appears that we were being artificially throttled to below
60fps by the widget paint events, and removing this manifests in a tp5
regression.
"Artificially" meaning "the computer has idle CPU and could issue
WM_PAINT at 60 fps but the OS decides not to?" Do we know why the OS
behaves in this way?
I've spent a lot of time looking into this, and the only difference is that
we paint the UI more times while the page is loading and this extra painting
delays the onLoad() event slightly. Unfortunately these extra paints don't
actually make to the screen currently (since we only composite to the screen
during the widget paint event), but OMTC will let us take full advantage of
this.
Currently this is about 5-8% tp5 regression across all platforms.
I've been looking at some improvements to our painting speed to try and cancel
out this change (Bug 781053), but we don't want to block DLBI on these.
Is this regression in Tp times matched by an improvement in perceived
performance because we're painting more often? If so, I think this
tradeoff makes sense (although I'd hope we had metrics which could
measure this perceived improvement). I'm a little wary of just taking a
5-8% Tp hit though!
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
