Closed
Bug 597258
Opened 14 years ago
Closed 12 years ago
Explore using -moz-element instead of the periodic canvas painting for Panorama thumbnails
Categories
(Firefox Graveyard :: Panorama, defect, P3)
Firefox Graveyard
Panorama
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: mitcho, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
11.44 KB,
patch
|
iangilman
:
feedback-
|
Details | Diff | Splinter Review |
We should explore using -moz-element instead of the current heartbeat-based periodic canvas painting to see what its performance characteristics are.
Updated•14 years ago
|
Assignee: nobody → seanedunn
Reporter | ||
Comment 1•14 years ago
|
||
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
Reporter | ||
Updated•14 years ago
|
Assignee: seanedunn → mitcho
Reporter | ||
Comment 2•14 years ago
|
||
Played around with this... got a proof of concept working in fifteen minutes... will polish and put up a patch.
Comment 3•14 years ago
|
||
Awesome, can't wait to see it. And see what the performance implications are.
Reporter | ||
Comment 4•14 years ago
|
||
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.
Attachment #480538 -
Flags: ui-review?(aza)
Attachment #480538 -
Flags: feedback?(ian)
Comment 5•14 years ago
|
||
Reporter | ||
Comment 6•14 years ago
|
||
Fixed a couple typos.
Attachment #480538 -
Attachment is obsolete: true
Attachment #480540 -
Flags: ui-review?(aza)
Attachment #480540 -
Flags: feedback?(ian)
Attachment #480538 -
Flags: ui-review?(aza)
Attachment #480538 -
Flags: feedback?(ian)
Comment 7•14 years ago
|
||
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 8•14 years ago
|
||
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-
Comment 9•14 years ago
|
||
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.
Reporter | ||
Updated•14 years ago
|
Attachment #480540 -
Flags: ui-review?(aza)
Reporter | ||
Comment 11•14 years ago
|
||
Thanks Robert. We'll keep this as a future item then.
Assignee: mitcho → nobody
Comment 12•14 years ago
|
||
(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.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•