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.

Pretty much ditto comment 0 except Thinkpad W520 & using discrete graphics only (nVidia Quadro M1000 iirc).

We should make sure to initialize our white DT to white completely on first draw.

Improved as per Nical's suggestion.

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.

I applied this patch on my w520 and am still seeing black boxes. Flash also flickers with black frames.

(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?

I haven't seen it, but I don't spend much time on tbpl on that machine.

(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.

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.

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?

(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.

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.

Is this still biting you Ryan?

Yes

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.

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.

(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.

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.

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.