963952 - OMTC black screen and GUI Glitches

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[Semtex]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140125030205

Steps to reproduce:

STR:
1. enable OMTC.
2. restart browser
3. open few tabs
4. start switching  between tabs, reload 2 or 3 at same time


Actual results:

5. after while nightly looks like: http://wstaw.org/m/2014/01/25/nightly.png
all tabs.


Expected results:

Nightly suppose works and look normal

Confirmed also here: http://forums.mozillazine.org/viewtopic.php?p=13324595#p13324595

While testing I was also "hit" with this crash: https://crash-stats.mozilla.com/report/index/3416090e-d930-4270-a453-3c9072140125

There are also other glitches when OMTC enabled, tabs, navbar disappears etc.

Comment 1

[Gary [:streetwolf52]]

OMTC enabled. I was scrolling through about:support and blocks of text turned all black then would eventually clear up with a little more scrolling.  Happens every now and then on other sites too.

On Windows 8.1 Pro x64.

Comment 2

[Gary [:streetwolf52]]

Attachment: Video glitch when OMTC is enabled.

Comment 3

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Confirmed here with Nightly 32bit on Windows 7 64bit.

Comment 4

[wojtekka]

I can confirm this too. Latest Nightly, AMD HD7850 latest WHQL driver on Windows 8.1 x64. When I resize the main window the problem goes away.

Comment 5

[Louis-Rémi BABE]

I had "layers.acceleration.force-enabled" for quite some time and glitches started to appear a few days ago.
Here's an example: http://youtu.be/GZIvyGS3CO0

I'm on Linux 64 with latest nightly

Comment 6

[Tom S [:evilpie]]

This seems to cause trouble for a lot of people, who want to test e10s on windows.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I did some debugging of this today. It's pretty easy to reproduce in Windows with e10s and hardware acceleration. I'm not sure how to fix it, but here's the problem:

We start with the D3D11 compositor. Later on, something tries to create a widget where mTransparencyMode == eTransparencyTransparent. We have some code [1] that chooses not to use the D3D11 compositor in that case. Without e10s, we would fall back to not using OMTC. But with e10s, we require OMTC, so we use the basic compositor instead.

When we create a basic compositor, the constructor [2] sets sBackend = LayersBackend::LAYERS_BASIC. This overrides the previous value, which was D3D11. A little later on, we get to a call to CreateDeprecatedTextureHost [3]. It switches on the value of sBackend and calls CreateBasicDeprecatedTextureHost. That function asserts because aDescriptorType is TSurfaceDescriptorD3D10.

It seems like the existence of Compositor::GetBackend() is fundamentally at odds with having multiple compositor backends at once, which we seem to need for electrolysis. Can we get rid of these calls?

[1] http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#6540
[2] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/basic/BasicCompositor.cpp#230
[3] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/TextureHost.cpp#136

Comment 8

[Matt Woodrow (:mattwoodrow)]

We currently have the requirement that we only ever have a single compositor backend.

We used to have a lot of callers depending on the static Compositor::GetBackend(), but a lot of those are gone now.

I'm not sure what else is depending on this, other than simplicity.

Nico, do you remember anything else that relies on this?

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I looked into this a bit more and I guess we don't actually need to use OMTC at all for this transparent widget. It doesn't appear to contain remote content. I think this should be pretty easy to fix.

Comment 10

[Nicolas Silva [:nical]]

(In reply to Bill McCloskey (:billm) from comment #7)
> I did some debugging of this today. It's pretty easy to reproduce in Windows
> with e10s and hardware acceleration. I'm not sure how to fix it, but here's
> the problem:
> 
> We start with the D3D11 compositor. Later on, something tries to create a
> widget where mTransparencyMode == eTransparencyTransparent. We have some
> code [1] that chooses not to use the D3D11 compositor in that case. Without
> e10s, we would fall back to not using OMTC. But with e10s, we require OMTC,
> so we use the basic compositor instead.

Gosh! Thanks for finding that.

We don't handle this. At the moment some of our code expects that we have only one backend using OMTC at the same time, and we don't expect sBackend to change. It got a little bit better with a patch we landed recently but we still rely a bit on sBackend.

> It seems like the existence of Compositor::GetBackend() is fundamentally at
> odds with having multiple compositor backends at once, which we seem to need
> for electrolysis. Can we get rid of these calls?

We will need to apparently. Well, Matt, we have another reason to enforce 1-1 relationship between SurfaceDescriptor type and TextureHost class, now that we know we can't rely on Compositor::GetBackendType() :)

Comment 11

[Nicolas Silva [:nical]]

(In reply to Semtex from comment #0)
> While testing I was also "hit" with this crash:
> https://crash-stats.mozilla.com/report/index/3416090e-d930-4270-a453-
> 3c9072140125

I don't have the bug number but I know there is a bug tracking this issue and someone on it.

Comment 12

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: windows-fix

This patch fixes the problem by not using OMTC for these transparent windows.

Comment 13

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f78468f352e4

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f78468f352e4

Comment 15

[Gary [:streetwolf52]]

Sorry to say I still get the occasional black screens and corruption on my toolbars when OMTC is enabled.


 	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0

Comment 16

[Gary [:streetwolf52]]

I'm wondering whether this is another instance of AMD cards not getting along with OMTC.

Comment 17

[Gary [:streetwolf52]]

Graphics
--------

Adapter Description: AMD Radeon HD 7900 Series
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 3072
Device ID: 0x6798
Direct2D Enabled: true
DirectWrite Enabled: true (6.3.9600.16384)
Driver Date: 1-31-2014
Driver Version: 13.350.1005.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 7900 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Comment 18

[Tom S [:evilpie]]

Gary, please open a new bug.

Comment 19

[Gary [:streetwolf52]]

Filed  https://bugzilla.mozilla.org/show_bug.cgi?id=973035

Comment 20

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Backed out the assertion since it's triggering kind of a lot.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2fc3f9509b0

Comment 21

[Paul Silaghi, QA [:pauly]]

Reproduced in Nightly 2014-01-27, Win 7 x64 while switching tabs.
Verified fixed FF 31 RC 2.