Closed
Bug 627828
Opened 13 years ago
Closed 11 years ago
Allow custom <browser remote> backgrounds without killing async panning perf
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: cjones, Unassigned)
References
Details
Bug 593310 adds a hard-coded background image as a temporary hack for beta4 (hopefully!). That's not what anyone wants. In the frontend, the goals for the background are probably - iterate quickly with different background images - allow extensions/personas to set a custom image We found out in bug 593310 that, at least, a simple implementation that puts the background in a <div> behind the <browser> isn't fast enough. The problems there were (i) each pan changed the background position, incurring a reflow; (ii) the div got its own thebes layer the size of the <browser>, wasting memory; (iii) the div had to be redrawn on each paint (AFAICT); (iv) redrawing a tiled image looks slow, if I read imgFrame correctly. All of this conspired to make drawing the background more expensive than drawing the <browser remote> usually, which is obviously bad. In the platform, the (conflicting) goals are - keep the spec as CSS-y as possible; already have background-image and repeat - re-use existing layout code when possible - have the background image drawn with the tiled ImageLayer fast-path - allow the background to be drawn similarly efficiently with GL (With our current code, the last goal above means images would be limited to power-of-two dimensions :/.) It's not clear how SVG images or -moz-element would fit here. I'd love to make our generic repeated-image drawing code use tiled ImageLayers, but that's a pretty substantial project that adds risk to desktop. A feasible compromise for 4.0 might be - set background-image and repeat on <browser remote> - build a display list honoring those - when layer-izing nsDisplayRemote, only respect display items that match our "fast" criteria This is very hand-wavy, I don't know all the details here. Thoughts?
Layerizing the nsDisplayBackground for specific cases of <browser remote> backgrounds shouldn't add much risk.
Reporter | ||
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•