1682595 - Scrolling up on Android always uses an extra picture cache tile, scrolling down does not

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Markus Stange [:mstange]]

Attachment: screenshot when scrolling down

Steps to reproduce:

1. Install GeckoView-example.apk on your Android phone (32 bit, 64 bit).
2. Go to about:config and enable gfx.webrender.debug.picture-caching.
3. Go to https://developer.mozilla.org/en-US/
4. Scroll up and down a bit.

Expected results:
The picture caching overlay should only display moving tiles.

Actual results:
While scrolling up, the picture caching overlay displays one fixed tile on top at the top edge.

Comment 1

[Markus Stange [:mstange]]

Attachment: screenshot when scrolling up

Comment 2

[Jamie Nicol [:jnicol]]

Does this only affect android, Markus? Do you know if it's a regression?

Any ideas what could be causing this Glenn?

Comment 3

[Glenn Watson [:gw]]

I can reproduce this in the geckoview example app linked above, but I can't reproduce it in fenix nightly, which is interesting.

From the debug display the content is s=1 (slice 1) and the fixed tile that shows up is a background tile s=0 (slice 0) that is behind the content. So this is probably the fixed background color provided for checkerboarding.

We can also see from the debug overlay that both the scrolling and fixed tiles are being detected as opaque, and that the background tile is not allocating any texture memory (surface=Color).

The first thing I'd check is what's occurring with occlusion culling of tiles. I'd expect that background tile is always occluded, and maybe due to some float accuracy issues or similar, it's sometimes not being detected as occluded?

I don't have an android env set up right now to test - could you add some logs around [1] and see if the tile occlusion calculations change depending on when the issue is occurring?

[1] https://searchfox.org/mozilla-central/rev/c7cf087b6e1384608ca3989f042f12f7cabd0a5f/gfx/wr/webrender/src/picture.rs#5219

Comment 4

[Jamie Nicol [:jnicol]]

Mozregression points to this first occurring in geckoview example due to bug 1500644, which added the dynamic toolbar. I don't want to say that caused the regression, because I assume this may have been present in Fenix for a lot longer.

Glenn, I also couldn't reproduce in Fenix initially, but then I realized I had disabled the dynamic toolbar. I can reproduce in fenix if I re-enable the dynamic toolbar, had you also disabled the dynamic toolbar?

I added the logging you suggested. When scrolling down, all the tiles of slice 0 are occluded by a 1080x2226 at (0, 0). However, when I scroll back up, they are occluded by a 1080x2223 at (0, 3) rect. Therefore the top row of tiles is not fully occluded. I'll try to see where that y=3 value is coming from

Comment 5

[Jamie Nicol [:jnicol]]

The occluder gets added here. When scrolling down, the offset in local_clip_rect gets cancelled out by the offset in map_pic_to_world, resulting in a rect at offset 0. However, when scrolling up the offset in the space mapper is off by 3 compared to the local_clip_rect. The scroll offset continues to cancel out the clip rect exactly, but it's added together with the additional offset of (0, 3) which comes from the parent node here. I'm not sure why.