Random black artifacts on TBPL with Windows OMTC

RESOLVED INCOMPLETE

Status

()

Core
Graphics
RESOLVED INCOMPLETE
4 years ago
2 years ago

People

(Reporter: RyanVM, Assigned: bas)

Tracking

({regression})

Trunk
x86_64
Windows 8.1
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Created attachment 8433591 [details]
screenshot

When using TBPL, I'll occasionally get artifacts that appear on the screen as black boxes (like the screenshot shows) or black lines. If I wait a bit, they sometimes go away on their own without me having to do anything.

I've been seeing this since at least some time last week. I'm pretty sure this is something that started more recently than OMTC being enabled.

I'm on Win8.1 x64 w/ an Optimus setup (Thinkpad W530). Drivers are up to date for both GPUs.
Blocks: 899785

Comment 1

4 years ago
Pretty much ditto comment 0 except Thinkpad W520 & using discrete graphics only (nVidia Quadro M1000 iirc).
Keywords: regression
(Assignee)

Updated

4 years ago
Assignee: nobody → bas
Status: NEW → ASSIGNED
(Assignee)

Comment 2

4 years ago
Created attachment 8441449 [details] [diff] [review]
Properly initialize the white buffer to white

We should make sure to initialize our white DT to white completely on first draw.
Attachment #8441449 - Flags: review?(nical.bugzilla)
(Assignee)

Comment 3

4 years ago
Created attachment 8441512 [details] [diff] [review]
Properly initialize the white buffer to white v2

Improved as per Nical's suggestion.
Attachment #8441449 - Attachment is obsolete: true
Attachment #8441449 - Flags: review?(nical.bugzilla)
Attachment #8441512 - Flags: review?(nical.bugzilla)
Comment on attachment 8441512 [details] [diff] [review]
Properly initialize the white buffer to white v2

Review of attachment 8441512 [details] [diff] [review]:
-----------------------------------------------------------------

Good, I'll file a followup bug for TextureClientX11 and GrallocTextureClient which to have this implemented as well.
Attachment #8441512 - Flags: review?(nical.bugzilla) → review+
I applied this patch on my w520 and am still seeing black boxes. Flash also flickers with black frames.
(Assignee)

Comment 7

4 years ago
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5)
> I applied this patch on my w520 and am still seeing black boxes. Flash also
> flickers with black frames.

If RyanVM can confirm the issue he reported is fixed, could you file a separate report? The issue in this bug seems fixed by this patch, you could be stuck with faulty drivers, try downloading updated intel drivers from the Intel website (auto-update will keep you stuck on 2011 :()

Matt, did you happen to see this on your W520?
Flags: needinfo?(matt.woodrow)
I haven't seen it, but I don't spend much time on tbpl on that machine.
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 9

4 years ago
(In reply to Matt Woodrow (:mattwoodrow) from comment #8)
> I haven't seen it, but I don't spend much time on tbpl on that machine.

I'm rather referring to the problems jaws sees where much more significant blackness, i.e. when using Zimbra his entire screen appears to turn black.
https://hg.mozilla.org/mozilla-central/rev/6419d2007c97
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
(Reporter)

Comment 11

4 years ago
I updated my build as soon as this was merged to m-c today. Unfortunately, I just hit an instance of it. It was shorter-lived than usual, though. And it was the first one I've seen so far today, so the frequency seems down.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla33 → ---
Comment on attachment 8441512 [details] [diff] [review]
Properly initialize the white buffer to white v2

Review of attachment 8441512 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/d3d11/TextureD3D11.cpp
@@ +181,5 @@
>    mIsLocked = true;
>  
>    if (mNeedsClear) {
>      mDrawTarget = BorrowDrawTarget();
>      mDrawTarget->ClearRect(Rect(0, 0, GetSize().width, GetSize().height));

D2D appears to always use R8G8B8A8 surfaces, even if we requested an opaque one. Doesn't that mean we have to clear to black, rather than transparent here?
(Assignee)

Comment 13

4 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4][PTO June 19-22] from comment #11)
> I updated my build as soon as this was merged to m-c today. Unfortunately, I
> just hit an instance of it. It was shorter-lived than usual, though. And it
> was the first one I've seen so far today, so the frequency seems down.

I can't seem to reproduce the issue anymore, if you see it more often, any chance you could let me know where you ran into it and if there's any specific way to trigger it?

 (In reply to Matt Woodrow (:mattwoodrow) from comment #12)
> Comment on attachment 8441512 [details] [diff] [review]
> Properly initialize the white buffer to white v2
> 
> Review of attachment 8441512 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/layers/d3d11/TextureD3D11.cpp
> @@ +181,5 @@
> >    mIsLocked = true;
> >  
> >    if (mNeedsClear) {
> >      mDrawTarget = BorrowDrawTarget();
> >      mDrawTarget->ClearRect(Rect(0, 0, GetSize().width, GetSize().height));
> 
> D2D appears to always use R8G8B8A8 surfaces, even if we requested an opaque
> one. Doesn't that mean we have to clear to black, rather than transparent
> here?

For the record here. Discussed this on IRC and concluded the code is fine.
(Reporter)

Comment 14

4 years ago
Still hitting this FTR, albeit not at the frequency as before. The way I usually hit it is when using the 'n' key to skip to the next unstarred failure on and the page has to scroll to do so.
(Assignee)

Updated

4 years ago
Blocks: 1036457
(Assignee)

Comment 15

4 years ago
Is this still biting you Ryan?
(Reporter)

Comment 16

4 years ago
Yes
(Assignee)

Comment 17

4 years ago
I've discussed this with RyanVM on IRC. The occurrence of this bug is about once a day for an intense TBPL user, the severity is also very low. Reproducing it is proving very difficult. I believe we should not block on this for aurora, and hope somewhere in the wild as this rides the trains a user will run into a more reproducible case.
No longer blocks: 1036457
(Reporter)

Comment 18

4 years ago
After my recent run-in with bug 1068881 (which had some similar symptoms to this - i.e. black boxes all over the place when switching to a different tab and back), it occurred to me that my default TBPL zoom setting is 90%. I'm wondering if that's a contributing factor here.

I'm going to run at default and see how that goes. If it goes away, maybe you'll be able to reproduce again with that changed.
(Reporter)

Comment 19

4 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #18)
> I'm going to run at default and see how that goes. If it goes away, maybe
> you'll be able to reproduce again with that changed.

Nope, just hit black boxes still.

Comment 20

3 years ago
I get a black rectangle everytime on the top/left cell (if that's where the focus is) on https://docs.google.com/spreadsheets/d/1WMbOIqT2cxvOPi-2AD6UqvZWfZ89CKbfrevSzYNYBG4/edit?pli=1#gid=0
Just scroll down and up again. The cell will show up black, then become white as expected.
With OMTC disabled, I can't reproduce it.
(Reporter)

Updated

2 years ago
See Also: → bug 1216349
(Reporter)

Comment 21

2 years ago
TBPL isn't around anymore, so there's no way to verify that this does or doesn't reproduce anymore. But I'm optimistic that the underlying issue is taken care of with the work in bug 1216349.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.