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)

x86_64
Linux
defect
Not set
normal

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.
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.