User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180316220124 Steps to reproduce: opened the page contained in the archive with Webrender active. System: AMD Kaveri 7650k, Linux 4.15.9, Mesa-17.3.6, radeonsi, amdgpu Actual results: only when scrolling with the mouse, drawing the page in question sometimes takes a long time. however as soon as I click at a not-yet-painted area it is drawn immediatly: https://youtu.be/re5Rkk0LOoY Looks like some flush operation is missing somewhere. When scrolled with the keyboard, it works as expected. Expected results: WebRender should behave like the OpenGL compositor, and simply redraw previously obscured areas when scrolling.

I can also reproduce the issue on Windows10 Nightly61.0a1 64bit.

mozregression --good 2018-03-01 --bad 2018-03-16 --pref gfx.webrender.all:true javascript.enabled:false startup.homepage_welcome_url:"http://localhost/background_repaint/background_broken.html" > 8:09.95 INFO: Last good revision: cfc5d19e856fc43766669069b7e2695dd519e5c3 > 8:09.95 INFO: First bad revision: 81f389c2524e58b4b95844667719cc1642573019 > 8:09.95 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cfc5d19e856fc43766669069b7e2695dd519e5c3&tochange=81f389c2524e58b4b95844667719cc1642573019 > 81f389c2524e Kartikaya Gupta — Bug 1440664 - Update reftest annotation for changes in WR PR 2471. r=jrmuizel > 507a25c3afd0 Kartikaya Gupta — Bug 1440664 - Update reftest annotation for WR PR 2443. r=jrmuizel > 6098d2c015d7 Kartikaya Gupta — Bug 1440664 - Re-generate FFI header. r=jrmuizel > a5991299ebd0 Kartikaya Gupta — Bug 1440664 - Update Cargo lockfiles and re-vendor rust dependencies. r=jrmuizel > c066c419e378 Martin Robinson — Bug 1440664 - Update gecko WR bindings for API changes in WR PR 2449. r=kats > 6f54af02c2e6 Kartikaya Gupta — Bug 1440664 - Update webrender to commit 22b831c02479eea31821f49a0fac7dd699083557. r=jrmuizel try build from bug 1440664: > WR @ 992dbd3f07b143f35581012082aa59fbda7c387e mozregression --repo try --launch 4916bd1bb3e9470ea106ebf45859b68b2a1b474c --pref gfx.webrender.all:true javascript.enabled:false startup.homepage_welcome_url:"http://localhost/background_repaint/background_broken.html" bad Regression range: https://github.com/servo/webrender/compare/8a19316a733a484bf9bafb8257e3008b1418bfe4...992dbd3f07b143f35581012082aa59fbda7c387e = servo/webrender#2362

Another redrawing bug with the same regression range is this one: 1. Go to https://github.com/devtools-html/perf.html/projects/4 2. Move your mouse into the "In Sprint" box, between the left edge of the box and the left edge of the white cards within the box. 3. Quickly scroll up and down. During scrolling, sometimes parts of the cards' white backgrounds are missing.

STR from comment 0: I put the test case online at https://staktrace.github.io/moz-pages/bug/1446626/index.html so it's easier to access. I can reproduce the issue on both macOS and windows nightly. STR from comment 3: I can reproduce this on macOS nightly but not on windows nightly. At the moment the "In Sprint" box isn't scrollable (too few cards in it) but the same issue is visible with one of other boxes that is scrollable (e.g. the "To Do" box). Scroll at a medium speed; as cards come into view from the bottom they often have their backgrounds missing for a second until a repaint happens. In both cases it looks like stuff that is clipped out isn't getting rendered when it async-scrolls into the visible area. There is an enclosing div with border-radius, and removing the border-radius makes the issue go away. It's likely that there are multiple clips on the display items for the background, and there's some bad interaction between the rounded clips and scrolling clips.

As far as I can tell the gecko display list and WR display list seem correct for this case. The green rectangle (in the reduced test case) has three clips. The innermost is from the displayport of the enclosing scrollframe, and as such, it scrolls with the enclosing scrollframe. The next one is the one with the rounded corners, and that clip scrolls with the root scrollframe. And then there's the clip from the root scrollframe. So this seems to be a bug in WR's handling of the clip chain. Martin, do you have cycles to take a look at this?

Sure. I should be able to take a look at this in the next couple days.

Thanks!

Hey Kats, I have been investigating this and I think I have a sense of what the general problem is. There are two scroll frames in the content display list (which, I assume, are created for each overflow:auto div). The green rectangle is assigned a clip chain with three clips. Two of these are not important. The important clip, the second in the clip chain, is a child of the first scroll frame. The green rectangle is a child of the second scroll frame. During async scrolling the scroll position of the second scroll frame changes, but not the first scroll frame. This means that important clip gradually moves outside the viewport. I think what is happening is that the next time Gecko sends a display list, it "manually" fixes up the position of the items inside the second scroll frame. The reason I think this is happening is that I took a capture before and after "fixing" the missing content with a mouse click. In the second capture many of the items inside the second scroll frame had their y position change from 20 to -664.

(In reply to Martin Robinson (email:mrobinson@igalia.com) from comment #9) > Hey Kats, I have been investigating this and I think I have a sense of what > the general problem is. There are two scroll frames in the content display > list (which, I assume, are created for each overflow:auto div). There's only one overflow:auto div in the reduced test case - the first scrollframe would be for the root content element (i.e. the <html> or <body>) and is not actually scrollable because the contents (#mailview-right) exactly fill up the available area. > The green > rectangle is assigned a clip chain with three clips. Two of these are not > important. The important clip, the second in the clip chain, is a child of > the first scroll frame. Yup, based on my recollection and comment 6, that second clip comes from the border-radius on #mailview-right, which is attached to the first scrollframe (i.e. it should never move). > The green rectangle is a child of the second scroll > frame. During async scrolling the scroll position of the second scroll frame > changes, but not the first scroll frame. This means that important clip > gradually moves outside the viewport. So this part seems the bit that's wrong - the important clip is attached to the first scrollframe so it shouldn't move when the second scrollframe changes. Do you agree? > I think what is happening is that the next time Gecko sends a display list, > it "manually" fixes up the position of the items inside the second scroll > frame. The reason I think this is happening is that I took a capture before > and after "fixing" the missing content with a mouse click. In the second > capture many of the items inside the second scroll frame had their y > position change from 20 to -664. Yeah, when we do a main thread repaint we redraw everything relative to the current scroll position and discard the async scroll. So that's what you're seeing here.

You're right. After quite a bit more exploration, I think I've tracked down the issue to a problem with stale brush segmentation data in the GPU cache. I hope to have a fix posted for this tomorrow in Servo.

Yesterday, I meant that I'd post a fix for this in WebRender. :) The fix is here: https://github.com/servo/webrender/pull/2859.

Great, thanks!

I tried pretty hard to turn the reduced test case into a reftest that would fail in the same way, but I was unsuccesful. I don't think any of the existing mechanisms in the reftest harness allow simulating this behaviour exactly.

The upstream fix has landed. Is this fixed now?

No, the WR update that contained the upstream fix (bug 1474300) was backed out of m-c, because of crashes (bug 1475829). A fix for the crasher landed in servo/webrender#2899 but hasn't been confirmed yet. At any rate the next WR update will fix this bug.

Moving the dep to the next WR update.

This is fixed with the WR update.

Due to the fact that the Webrender is disabled on beta, removing the QE flag.