[Tracking Requested - why for this release]: +++ This bug was initially created as a clone of Bug #1266051 +++ Black line/rectangle appears after scrolling. And It persist. The problem occurs with/without e10s. STR 1. Open URL 2. Scroll up and down by thumb or mouse wheel Graphics -------- Features Compositing: Direct3D 11 Asynchronous Pan/Zoom: wheel input enabled; touch input enabled WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding: Yes; Using D3D9 API Direct2D: true DirectWrite: true (6.2.9200.17568) GPU #1 Active: Yes Description: AMD Radeon HD 6450 Vendor ID: 0x1002 Device ID: 0x6779 Driver Version: 15.200.1062.1003 Driver Date: 7-28-2015 Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Subsys ID: 23111787 RAM: 1024

Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=336a70a8dfe4a980627b43da56c8b93658d3fba9&tochange=f5de44ecf07f3cbd369015663b72d452fda6d177 Regressed by: Bug 1236043

Looks like an existing bug in our D3D11 compositor which was exposed by bug 1236043. I can reproduce this on one of the Windows 7 machines in the office. I'll need to create a reduced testcase. The scrollable layer in question switches between grayscale text antialiasing and subpixel text antialiasing during scrolling. I don't know yet why that is.

Wow, thanks!

Bas, would you like to fix this?

Oh, I've only tested this testcase in non-e10s mode. If you want to convert it to a reftest you'll probably need to add an explicit 0,0,500,500 display port.

Note this bug does not seem to reproduce with e10s.

It reproduces with e10s if you turn off APZ. That may even make it easier to debug.

I can reproduce with e10s+APZ both enabled as well as e10s disabled.

Hrm, when examining this bug it appears to be the background layer does not have the black area in its visible region, and the foreground layer is transparent in that area. So it seems like nothing will be drawn there and that's the cause of the black area. It's possibly I'm missing something but I don't think I am. So it would appear something is wrong with the visible region calculation.

Thanks! I'll take a look.

Can you find out how the foreground has become transparent in that area? The layer has a forced background color which is drawn by DrawForcedBackgroundColor (in FrameLayerBuilder.cpp) into the bounds of the layer's visible region at the start of FrameLayerBuilder::DrawPaintedLayer.

(In reply to Markus Stange [:mstange] from comment #12) > Can you find out how the foreground has become transparent in that area? The > layer has a forced background color which is drawn by > DrawForcedBackgroundColor (in FrameLayerBuilder.cpp) into the bounds of the > layer's visible region at the start of FrameLayerBuilder::DrawPaintedLayer. Sounds good. I'll have a look at that this weekend.

A similar problem is described in bug 1266051. It is another regression from bug 1236043, but on Linux.

Hmm, that one actually looks like the same problem. So either we have the same bug on Linux or this isn't actually a bug in the compositor. Bas, have you had any luck debugging this?

(In reply to Markus Stange [:mstange] from comment #16) > Hmm, that one actually looks like the same problem. So either we have the > same bug on Linux or this isn't actually a bug in the compositor. > > Bas, have you had any luck debugging this? Not really, I had a quick look but it's not easy to see how exactly it's drawn. And then I forgot about it tbh. But I believe we clip to the invalid region when drawing don't we? So as long as something isn't in the visible region it will be transparent there if it's a transparent layer. Fwiw, it didn't 'feel' like a compositor bug to me when I looked at this. But that's a very intuitive statement that I can't really back up that well.

I can reproduce this with Basic Compositor on OS X.

This happens because RotatedContentBuffer::BeginPaint requests a paint region that is larger than the visible region, because we hit the neededRegion = destBufferRect case. However, DrawForcedBackgroundColor only fills the intersection of the draw region and the visible region. After drawing, the draw region is added to the valid region of the layer, even though parts of the valid region have not been filled with the forced background color. Later, when the visible region is enlarged due to new content in the layer, we don't redraw the parts inside the valid region that haven't changed, and the uncleared parts become visible because they're now inside the visible region.

We need to do this because the entire draw region will be added to the layer's valid region after drawing. If there are parts in the valid region that are not in the visible region, we still need those parts to have valid content, because in a later frame the visible region may grow to include those parts. Review commit: https://reviewboard.mozilla.org/r/50983/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/50983/

Comment on attachment 8749472 [details] MozReview Request: Bug 1266161 - Make DrawForcedBackgroundColor fill the entire draw region, not just the layer's visible region. r?mattwoodrow https://reviewboard.mozilla.org/r/50983/#review47653

Comment on attachment 8749472 [details] MozReview Request: Bug 1266161 - Make DrawForcedBackgroundColor fill the entire draw region, not just the layer's visible region. r?mattwoodrow Review request updated; see interdiff: https://reviewboard.mozilla.org/r/50983/diff/1-2/

Comment on attachment 8749472 [details] MozReview Request: Bug 1266161 - Make DrawForcedBackgroundColor fill the entire draw region, not just the layer's visible region. r?mattwoodrow Approval Request Comment [Feature/regressing bug #]: regression from bug 1236043 [User impact if declined]: black boxes or garbage appearing on some websites [Describe test coverage new/current, TreeHerder]: this patch adds a test [Risks and why]: very low, well understood fix [String/UUID change made/needed]: none

Recent regression, tracking.

Comment on attachment 8749472 [details] MozReview Request: Bug 1266161 - Make DrawForcedBackgroundColor fill the entire draw region, not just the layer's visible region. r?mattwoodrow Includes test fixes. Please uplift, then we can verify on aurora.

I couldn't reproduce this on Mac OS X 10.9.5 and Win 10 64-bit. I did reproduce under Win 7 64-bit, where it is now fixed on latest Aurora 48.0a2 and latest Nightly 49.0a1 both builds from 2016-05-31.