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
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.
One possible explanation for the difference is I'm using background-blend-mode on the hero image on blog.wanderview.com.
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).
Jeff, any ideas on what we can do here to mitigate this problem?
For what its worth this reproduces on my open c v1.3 device as well.
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?
(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.
Ben, can you attach an image capture?
The effect flashes too quickly to take a screenshot. I'll need to record a video when I get back from vacation next week.
(In reply to Kartikaya Gupta (email:email@example.com) 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?
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.
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.
What do you mean by independently of the opacity change? Do you mean it still happens without dropping the opacity to 50%?
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.
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.
(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.
It seems folks have a decent handle on whats going on here, so not going to take the time to make a movie.
Fixed via bug 1013385, so duping.