Black boxes since 2014-04-11 with e10s off and D3D9 OMTC HWA

VERIFIED FIXED in Firefox 43

Status

()

VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: Oriol, Assigned: bas.schouten)

Tracking

({regression})

32 Branch
mozilla44
Unspecified
Windows
regression
Points:
---

Firefox Tracking Flags

(e10s-, firefox43+ verified, firefox44+ verified)

Details

Attachments

(5 attachments)

(Reporter)

Description

4 years ago
Posted file testcase
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151019030227

Steps to reproduce:

I occasionally see black boxes, specially when scrolling.
Finally I have been able to create a reproducible testcase.

Just make sure multi-process is disabled and OMTC hardware acceleration is enabled. I can reproduce with both D3D9 and D3D11. Then open the testcase.



Actual results:

JS will scroll automatically, and some black boxes will appear.


Expected results:

There should be no black boxes.

Last good nightly: 2014-05-20 cb9f34f73ebe
First bad nightly: 2014-05-21 9d8d16695f6a
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromcange=cb9f34f73ebe&tochange=9d8d16695f6a

Sadly it seems it's too late and the inbound builds have been removed.
(Reporter)

Updated

4 years ago
See Also: → bug 1211615
(Reporter)

Updated

4 years ago
Component: Untriaged → Graphics
OS: Unspecified → Windows
Product: Firefox → Core
Version: 44 Branch → 32 Branch
Bas, want to fix?
Flags: needinfo?(bas)
OMTC being enabled on Windows is in that range. Conveniently, I filed bug 1019909 around that time as well, but it fizzled out due to difficulties reproducing and eventually the move to Treeherder.
https://hg.mozilla.org/mozilla-central/rev/718a9852b60d
Blocks: 899785
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
See Also: → bug 1019909
(Reporter)

Updated

4 years ago
See Also: → bug 1217215
(Reporter)

Comment 3

4 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #2)
> OMTC being enabled on Windows is in that range.

True, enabling layers.offmainthreadcomposition.enabled manually produced this range for D3D9:

Last good nightly: 2014-04-10 690c810c8e3e
First bad nightly: 2014-04-11 d8c1b10c3a3d
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=690c810c8e3e&tochange=d8c1b10c3a3d

Since D3D11 has another range, I have filed bug 1217215.
(Reporter)

Updated

4 years ago
Summary: Black boxes since 2014-05-21 with e10s off, HWA on, OMTC on → Black boxes since 2014-04-11 with e10s off and D3D9 OMTC HWA
(Assignee)

Updated

4 years ago
Assignee: nobody → bas
Status: NEW → ASSIGNED
Flags: needinfo?(bas)
tracking-e10s: --- → -
(Assignee)

Comment 4

3 years ago
Here's a couple of interesting observations:

1. Scroll the test case down to below the vertical line's start, and scroll back up, the black areas are now permanently gone.
2. Wait for the layers to become inactive, the black areas are now permanently gone.
3. Switch tabs away and back, black areas are now permanently gone.
(Assignee)

Comment 5

3 years ago
(Assignee)

Comment 6

3 years ago
(Assignee)

Comment 7

3 years ago
(Assignee)

Comment 8

3 years ago
The transition from the second to the third frame here is interesting. Notice some odd stuff going on in the state in the second frame. Note they share the same 375x615 TextureHost. In the second frame almost the entire TextureHost is considered Valid, even though that area isn't in the visible region at all. In the subsequent third frame we see that that area considered valid in the second frame, but that is not in the visible region, is black. That makes complete sense.

So current observations suggest, that perhaps counterintuitively, thinks go wrong in the -second- frame where there are no artifacts yet, by overestimating the validity of the TextureHost.
(Assignee)

Comment 9

3 years ago
The problem here is that we create a new texture host when the visible region changes between frame 1 and 2, we then copy the valid contents of the old one into the new one. When we send the updated region to the compositor though, that only contains the valid region that is also in the visible region. Which means that part of the new texture host is never uploaded.

This patch makes it so that when a new texture host is received by a content host, it will make sure to upload the entire old valid region regardless of whether it's in the current updated region.
Attachment #8678142 - Flags: review?(nical.bugzilla)
Should we uplift this?
Flags: needinfo?(bas)
Attachment #8678142 - Flags: review?(nical.bugzilla) → review+
https://hg.mozilla.org/mozilla-central/rev/c0e1ef583bb9
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
(Assignee)

Comment 13

3 years ago
(In reply to Milan Sreckovic [:milan] from comment #10)
> Should we uplift this?

Yes, probably, but I would like to wait a couple of days to make sure this doesn't cause any issues.
Flags: needinfo?(bas)
(Reporter)

Comment 14

3 years ago
The patch seems to fix bug 1217215 too. Maybe I shouldn't have separated it into a new bug? It had a different regression range, though.
I think you did the right thing given the different range. Feel free to dupe it over or close it out marked as depending on this bug, though.
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1217215
(Reporter)

Comment 17

3 years ago
(In reply to Bas Schouten (:bas.schouten) from comment #13)
> I would like to wait a couple of days to make sure this
> doesn't cause any issues.

Is it OK to uplift it now?
(Assignee)

Comment 18

3 years ago
Comment on attachment 8678142 [details] [diff] [review]
Upload the old valid region as well if our texture host changed

Approval Request Comment
[Feature/regressing bug #]: OMTC
[User impact if declined]: Black areas on websites
[Describe test coverage new/current, TreeHerder]: Nightly coverage
[Risks and why]: Low, tiny perf regression possibility
[String/UUID change made/needed]: None
Attachment #8678142 - Flags: approval-mozilla-beta?
Tracking since this is a regression and marking affected for 43.
status-firefox43: --- → affected
tracking-firefox43: --- → +
tracking-firefox44: --- → +
Comment on attachment 8678142 [details] [diff] [review]
Upload the old valid region as well if our texture host changed

Fix for another OMTC regression. OK to uplift to beta.
Attachment #8678142 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment 21

3 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/94c40ce2d93b
status-firefox43: affected → fixed
Flags: qe-verify+
Reproduced the initial issue using an old Nightly build (2015-10-24), verified that the issue is fixed using Firefox 43 beta 4 and latest Firefox Developer Edition 44.0a2 on Windows XP 32-bit.
Status: RESOLVED → VERIFIED
status-firefox43: fixed → verified
status-firefox44: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.