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

VERIFIED FIXED in Firefox 48

Status

()

Core
Graphics: Layers
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: Alice0775 White, Assigned: mstange)

Tracking

({regression})

48 Branch
mozilla49
Unspecified
Windows 7
regression
Points:
---
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox47 unaffected, firefox48+ verified, firefox49 verified)

Details

(Whiteboard: [gfx-noted], URL)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

2 years ago
Created attachment 8743411 [details]
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
(Reporter)

Updated

2 years ago
Summary: Black line/rectangle appears after scrolling. And It persist. → Black line/rectangle appears when scrolling. And It persist.
(Reporter)

Comment 1

2 years ago
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=336a70a8dfe4a980627b43da56c8b93658d3fba9&tochange=f5de44ecf07f3cbd369015663b72d452fda6d177

Regressed by: Bug 1236043
Blocks: 1236043
Flags: needinfo?(mstange)
Flags: needinfo?(jmuizelaar)
Keywords: regressionwindow-wanted
(Reporter)

Updated

2 years ago
No longer depends on: 1266051
(Reporter)

Updated

2 years ago
Component: Graphics → Graphics: Layers
Whiteboard: [gfx-noted]
(Assignee)

Comment 2

2 years ago
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)
(Reporter)

Comment 3

2 years ago
Created attachment 8743577 [details]
semi-reduced html
(Assignee)

Comment 4

2 years ago
Wow, thanks!
(Assignee)

Comment 5

2 years ago
Created attachment 8743980 [details]
testcase

Bas, would you like to fix this?
Attachment #8743577 - Attachment is obsolete: true
Flags: needinfo?(bas)
(Assignee)

Comment 6

2 years ago
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.
(Assignee)

Comment 8

2 years ago
It reproduces with e10s if you turn off APZ. That may even make it easier to debug.
(Reporter)

Comment 9

2 years ago
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)
(Assignee)

Comment 11

2 years ago
Thanks! I'll take a look.
Flags: needinfo?(mstange)
(Assignee)

Comment 12

2 years ago
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)
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1267999
A similar problem is described in bug 1266051. It is another regression from bug 1236043, but on Linux.
(Assignee)

Comment 16

2 years ago
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)
(Assignee)

Comment 18

2 years ago
I can reproduce this with Basic Compositor on OS X.
Assignee: bas → mstange
(Assignee)

Comment 19

2 years ago
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.
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1266051
(Assignee)

Comment 21

2 years ago
Created attachment 8749471 [details]
testcase
Attachment #8743980 - Attachment is obsolete: true
(Assignee)

Comment 23

2 years ago
Created attachment 8749472 [details]
MozReview Request: Bug 1266161 - Make DrawForcedBackgroundColor fill the entire draw region, not just the layer's visible region. r?mattwoodrow

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+
(Assignee)

Comment 25

2 years ago
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 27

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/88281a61cde8
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
(Assignee)

Comment 28

2 years ago
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.
tracking-firefox48: ? → +
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+

Comment 31

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/9337a7244e25
status-firefox48: affected → fixed
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
status-firefox48: fixed → verified
status-firefox49: fixed → verified
You need to log in before you can comment on or make changes to this bug.