Closed Bug 785933 Opened 7 years ago Closed 5 years ago

Use page background as "checkerboard" for APZC

Categories

(Core :: Panning and Zooming, defect, P4)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1013385

People

(Reporter: cjones, Unassigned)

References

Details

(Whiteboard: p=0)

We added code for fennec to extract the (body?) background-color and use that as the "checkerboard" pattern.  We should use that for apzc too.
Nice to have for parity with fennec at least, but haven't gotten any complaints about this.
Whiteboard: [tech-p3]
This would be a big improvement for Metro.  Currently we draw black for unpainted areas while scrolling, and white for unpainted areas when double-tap zooming.  Both are very distracting.
Component: Graphics: Layers → Panning and Zooming
OS: Linux → All
Hardware: x86_64 → All
nsCanvasBackground usually creates a color layer underlying the layer tree. We can probably walk the layer tree and fairly easily find this color layer and extract the color of it.
Blocks: metrobacklog
No longer blocks: metro-apzc
Whiteboard: [tech-p3]
Whiteboard: [defect]
Whiteboard: [defect] → [defect] p=0
Blocks: metrofxe10s
"Checkerboarding" happens when the content layer(s) are scrolled off so that they don't intersect the user-visible region. I would expect that the color layer mentioned in comment 2 would be made the size of the entire document and so would never be "scrolled off". Is that not the case? As long as the background color layer is always the size of the document we shouldn't even need to do anything on the APZ side to make this work.
Flags: needinfo?(bgirard)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)
> "Checkerboarding" happens when the content layer(s) are scrolled off so that
> they don't intersect the user-visible region. I would expect that the color
> layer mentioned in comment 2 would be made the size of the entire document
> and so would never be "scrolled off".

Color layers have visibility. They are mostly just a memory optimization. Here's a ColorLayer from a layers.dump:
ColorLayerComposite (0xaec36800) [visible=< (x=0, y=0, w=1200, h=1920); >] [opaqueContent] [color=rgba(0, 0, 0, 1)]

> As long as the
> background color layer is always the size of the document

Actually with subAPZC we could make it the size of the element (scrollPort). That way the background color of a frame wouldn't leak outside of it bounds.
Flags: needinfo?(bgirard)
(In reply to Benoit Girard (:BenWa) from comment #5)
> Color layers have visibility. They are mostly just a memory optimization.
> Here's a ColorLayer from a layers.dump:
> ColorLayerComposite (0xaec36800) [visible=< (x=0, y=0, w=1200, h=1920); >]
> [opaqueContent] [color=rgba(0, 0, 0, 1)]

Yeah so in that example the color layer is 1200x1920, right?. Is that not the size of the document? If not, why not?

> Actually with subAPZC we could make it the size of the element (scrollPort).
> That way the background color of a frame wouldn't leak outside of it bounds.

I don't think the leakage is a problem because of the cliprect applied by the scrollable container layer that will contain it. If we size the color layer to just the size of the scrollPort then as soon as you start panning async the background will appear cut off, no? The color layer is a child of the container layer that is being scrolled asynchronously so it will be subject to the async transform as well.
Priority: -- → P4
Whiteboard: [defect] p=0 → p=0
Forward-duping since this bug was originally filed for Fennec and things have changed since then. We still need this done for APZ but the new bug is probably more relevant.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1013385
You need to log in before you can comment on or make changes to this bug.