We should explore using -moz-element instead of the current heartbeat-based periodic canvas painting to see what its performance characteristics are.
From Rob's blog entry on -moz-element: > Note for browser UI and extension authors: eventually -moz-element will be the preferred way to render "live" copies of Web page contents (insteading of using MozAfterPaint/drawWindow). Right now, -moz-element can be used to render the contents of a <browser> element elsewhere, although it's less well-tested and is less tweakable for performance. Post-FF4, we can tie -moz-element into the layers framework so that in many cases --- such as tab thumbnails --- rendering -moz-element just recomposites a layer subtree, fully GPU-accelerated. http://weblogs.mozillazine.org/roc/archives/2010/08/mozelement_land.html
Played around with this... got a proof of concept working in fifteen minutes... will polish and put up a patch.
Awesome, can't wait to see it. And see what the performance implications are.
Known issues: - still thumbnails are no longer being cached and saved with the tab metadata. - unsure if we still need pausePainting. If we still want it, though, it should be renamed, as it no longer pauses painting... just pauses updating the title and favicon.
Fixed a couple typos.
This could be interesting to chromeless browser work too and Fennec uses this kind of mediator canvas right? People may also want to directly mediate browser rendering to a webgl texture, along the road.
Comment on attachment 480540 [details] [diff] [review] Patch v2 Very slick, mitcho! The big question, of course, is perf. To test, I made a group of a few tabs and tried dragging and resizing it. On my machine, at least, it's significantly chunkier with -moz-element than without. I also tried zoom in/out and got similar results. Do we know if there are any optimizations coming down the pike for -moz-element? If not, it seems like it's not going to work out, at least not as a general solution. It might be interesting to think about places it could be used, like just for tabs that are over a certain size threshold or something. The other thing we'd need to address if we wanted to use -moz-element is to make sure we can do thumbnail caching, especially once bug 595601 lands.
Attachment #480540 - Flags: feedback?(ian) → feedback-
We can ask roc about optimizations. My understanding is that there won't be any for Firefox 4. We should probably punt this to the future, which is sad.
Target Milestone: --- → Future
I don't really have anything to add beyond what was quoted in comment #1. We can make -moz-element very fast post-FF4, but we don't have the resources to do that now. I think for now you should stick with the canvas painting you've got.
Thanks Robert. We'll keep this as a future item then.
Assignee: mitcho → nobody
(In reply to comment #8) > The big question, of course, is perf. You should consider memory footprint too, inactive tabs use (or are supposed to use) considerably less memory e.g. due to image discarding. I don't know if -moz-element affects this, but if it does that would create a significant memory overhead. > Do we know if there are any optimizations coming down the pike for > -moz-element? If not, it seems like it's not going to work out, at least not as > a general solution. It might be interesting to think about places it could be > used, like just for tabs that are over a certain size threshold or something. It could be used for the last N active tabs for example or when the user hovers with his mouse over the tab for a moment. Another candidate where it could be used is the zoom transition, which often appears to be pixelated and stuttering.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.