1038214 - b2g displays incorrect layer on octopress MediumFox theme when scrolling quickly

Status: RESOLVED DUPLICATE of bug 1013385

(Core :: Graphics: Layers, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

Recently I updated my octopress blog with the MediumFox theme.  It uses a "hero" design where a large image at the top is hidden by the text as you scroll down.  On my v2.0 flame this works ok, but the hero and title flash through the text content as you scroll down.

To reproduce:

1) Visit the MediumFox theme live preview at:  http://adrianartiles.com/
2) Scroll down at a moderate to fast pace.
3) Observe that the hero title flashes on the screen while scrolling quickly.

It might be easier to see on my blog at http://blog.wanderview.com.

Scrolling slowly does not reproduce the problem.

Unfortunately I don't have a minimal test case isolating the content causing this.

Flame v122 base firmware
Update channel: aurora
Build ID: 20140712160202
Gaia Rev: ca022f81

Comment 1

[Botond Ballo [:botond]]

I can see this as well.

Possibly the top layer (the text content) checkerboards while scrolling quickly, and the bottom layer ("hero" and title) shows through.

Another issue I see on blog.wanderview.com but not adrianartiles.com is if you scroll back up quickly, so as to bring the "hero" image back into view, the bottom part of the image (exactly how much varies form one try to another) is black for a fraction of a second before being drawn.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

One possible explanation for the difference is I'm using background-blend-mode on the hero image on blog.wanderview.com.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

This problem happens because when scrolling quickly we drop down to low-precision rendering for the main content layer. This is rendered at 50% opacity so the other layers underneath show through. Setting the layers.low-precision-opacity pref to "1.0" fixes the problem (although the second issue botond pointed out in comment 1 still exists).

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Jeff, any ideas on what we can do here to mitigate this problem?

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

For what its worth this reproduces on my open c v1.3 device as well.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

On the v1.3 there is no opacity change.  The underlying layer just shows through when the top layer checkerboards.  So I guess its not quite the same problem.

Out of curiosity, what is the rational for using 50% opacity during low-precision rendering?  Wouldn't that increase the computational load exactly when we detect we are falling behind?  It seems opacity of 1.0 would be preferable, wouldn't it?

Comment 7

[Kartikaya Gupta (email:[e-mail])]

(In reply to Ben Kelly (PTO / back July 21) [:bkelly] from comment #6)
> Out of curiosity, what is the rational for using 50% opacity during
> low-precision rendering?  Wouldn't that increase the computational load
> exactly when we detect we are falling behind?  It seems opacity of 1.0 would
> be preferable, wouldn't it?

Using 100% opacity has the visual effect of making text look more bold, which was undesirable. I'm open to other suggestions on what to do here, see bug 1020778 for the full backstory.

The computational load here should be negligible because this is done entirely on the GPU and doesn't affect layout or rasterization work.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Ben, can you attach an image capture?

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

The effect flashes too quickly to take a screenshot.  I'll need to record a video when I get back from vacation next week.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> Using 100% opacity has the visual effect of making text look more bold,
> which was undesirable. I'm open to other suggestions on what to do here, see
> bug 1020778 for the full backstory.

Hmm, would it be possible to add a dummy layer with the same opaque background color as the top layer being rendered at low resolution?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Yes, I believe that should be possible. I attached a WIP to bug 1038416 that tries to do that. However I still see this bug on your website when the content checkerboards (i.e. outside the low-resolution area). We'd need to have a solid background the entire time, I think. Or it might be the correct behaviour - I'll have to look at the CSS to check.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Hm, I'm not really sure what the right thing here is. ni? to Matt who might be able to help. What we have is a fixed-position div with z-index -1 at the top of the page. And then the normal content which scrolls (on top of it, because z-index 0) with a margin-top:500px. This allows the fixed-position element to be visible when you're scrolled to the top, but it hides underneath as you scroll down. The problem is that when the content "checkerboards" we see the fixed-position div underneath coming through. This happens independently of low-res tiling and the opacity change.

My feeling is that somehow the scrolling content should have a background color layer which never checkerboards, and so the fixed-position div underneath doesn't become visible. I don't know if it's possible to have such a layer generated by layout. Alternatively, we need to paint in the background color (or something opaque at any rate) for the "checkerboard" area in the compositor, similar to how we do it for the overscroll.

I know Gordon from UX was also saying that have a checkerboard pattern would be a step up from just showing blank when checkerboarding, so maybe we should implement that.

Comment 13

[Matt Woodrow (:mattwoodrow)]

What do you mean by independently of the opacity change? Do you mean it still happens without dropping the opacity to 50%?

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Yes. Even with the opacity set to 100%, if you scroll fast enough you can get outside the low-res displayport area into true checkerboard land. When that happens we draw nothing for the top layer and you can see the fixed-position div underneat.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

I think this is the same fundamental problem as bug 1013385.

Comment 16

[Matt Woodrow (:mattwoodrow)]

Right, ok. In that case I agree, we need to either insert a solid color, or the checkerboard pattern when APZ scrolls past the bounaries of what we have content for.

Botond was looking at trying to compute an approximate background color for layers, could be useful to try pick an appropriate color to use.

Comment 17

[Botond Ballo [:botond]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #16)
> Botond was looking at trying to compute an approximate background color for
> layers, could be useful to try pick an appropriate color to use.

See bug 1014280 for this.

Comment 18

[Ben Kelly [:bkelly, not reviewing]]

It seems folks have a decent handle on whats going on here, so not going to take the time to make a movie.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

Fixed via bug 1013385, so duping.