Results indicate so far indicate that bug 626602 was a ~5% regression on win7. The regression pretty consistently goes away with readback disabled, replaced by a color-fill to the background surface instead of a copy from the read-back texture. To nail down the regression, it'd be best to find the tp4 pages that regressed worse (on the regressing runs; the results are very noisy) and then profile them. Bas notes that the vtune thread profiler could help diagnose contention. Because the readback task is fired off in the middle of painting, it's possible that the readback thread is locking the d3d device and choking out the main thread (/me waves hands). If so, we can be smarter about scheduling readback so that it doesn't interfere with the paint it was scheduled in. (It might still interfere with later paints.) With d3d9 we got an ~1-2% regression, and there's not really anything there that can be improved readback-wise. So that's probably a good target to aim at.
Bug 634844 might be relevant in that maybe it could win back some of the loss from readback, but it would be good to win overall.
Another possibility is do one slow-paint with alpha recovery in the hope that the plugin doesn't repaint. Then if it later invalidates, try to get a background for it. Alpha recovery is dog slow but off the firefox-bin page-load path. So, in theory, both plugin benchmarks and startup time could win. But it'd still be better to have faster readback.
That all sounds good.
A regression on d3d10 was never clearly established, and to my knowledge there haven't been complaints of worse perf in the field on d3d10, so this WFM. Can investigate heuristics later.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.