Spin-off from bug 497543 comment #74: "When thumbnailing a visible tab, we could just recompose the layer subtree for that tab. This should be very fast (apart from reading back from the GPU). With OMTC, it can be made asynchronous as well if necessary. This will require new layers API and some drawWindow implementation changes, though. We could make it even cheaper by making a new API to deliver a copy of the visible tab next time we recompose it normally; then we could keep a copy of what was composited for the visible tab, and read it back asynchronously."

We already have the support to do this use draw widget layers feature so morphing this bug into optimizing thumbnailing by using this feature.

(In reply to Benoit Girard (:BenWa) from comment #1) > We already have the support to do this use draw widget layers feature Do you mean DRAWWINDOW_USE_WIDGET_LAYERS? Last I heard there were various issues making that not suitable for use here (like maybe bug 678392 comment 48, but there are others I can't find at the moment). It also doesn't really cover the "async" parts of comment 0. I see we have asyncDrawXULElement now, but bug 619591 means there's no way to tell when it's done...

DRAWWINDOW_USE_WIDGET_LAYERS will only ever work for content that is currently visible on screen, so if you want to use this for background tabs it's not going to help.

We only currently need to capture tabs that are on screen, AFAIK, but having a fast/async way to do background tabs could be useful too.

We could extend DRAWWINDOW_USE_WIDGET_LAYERS to composite the screen without doing a finish with hardware compositing. This would be somewhat async since we wouldn't wait on the GPU to complete thus reducing main thread wait for thumbnail. That + off main thread encoding would help.

I discussed the issue with nical. It would be rather simple to extend the composer with an async API that would callback with a copy of the screen after the next redisplay.

https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI has a proposal for improving things here (not quite sure how that compares to bug 744100).

For reference, here is the Telemetry: http://telemetry.mozilla.org/#path=nightly/27/FX_THUMBNAILS_CAPTURE_TIME_MS 50% of cases are above 21ms, which is not good. 5% are 80ms, which is bad.