Closed Bug 1266161 Opened 8 years ago Closed 8 years ago

Black line/rectangle appears when scrolling. And It persist.

Categories

(Core :: Graphics: Layers, defect)

48 Branch
Unspecified
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla49
Tracking Status
firefox47 --- unaffected
firefox48 + verified
firefox49 --- verified

People

(Reporter: alice0775, Assigned: mstange)

References

()

Details

(Keywords: regression, Whiteboard: [gfx-noted])

Attachments

(3 files, 2 obsolete files)

Attached image screenshot
[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
Summary: Black line/rectangle appears after scrolling. And It persist. → Black line/rectangle appears when scrolling. And It persist.
No longer depends on: 1266051
Component: Graphics → Graphics: Layers
Whiteboard: [gfx-noted]
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.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Flags: needinfo?(mstange)
Flags: needinfo?(jmuizelaar)
Attached file semi-reduced html (obsolete) —
Wow, thanks!
Attached file testcase (obsolete) —
Bas, would you like to fix this?
Attachment #8743577 - Attachment is obsolete: true
Flags: needinfo?(bas)
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.
Assignee: mstange → bas
Flags: needinfo?(bas)
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.
Flags: needinfo?(mstange)
Thanks! I'll take a look.
Flags: needinfo?(mstange)
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.
Flags: needinfo?(bas)
(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.
Flags: needinfo?(bas)
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?
Flags: needinfo?(bas)
(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.
Flags: needinfo?(bas)
I can reproduce this with Basic Compositor on OS X.
Assignee: bas → mstange
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.
Attached file testcase
Attachment #8743980 - Attachment is obsolete: true
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/
Attachment #8749472 - Flags: review?(matt.woodrow)
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
Attachment #8749472 - Flags: review?(matt.woodrow) → review+
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/
https://hg.mozilla.org/mozilla-central/rev/88281a61cde8
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
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
Attachment #8749472 - Flags: approval-mozilla-aurora?
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.
Attachment #8749472 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.