Closed Bug 963952 Opened 6 years ago Closed 6 years ago

OMTC black screen and GUI Glitches

Categories

(Core :: Graphics: Layers, defect)

29 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox31 --- verified

People

(Reporter: semtex2, Assigned: billm)

References

Details

Attachments

(2 files)

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.
Blocks: 899785
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
This seems to cause trouble for a lot of people, who want to test e10s on windows.
Blocks: core-e10s
See Also: → 966906
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
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?
Flags: needinfo?(nical.bugzilla)
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.
(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() :)
Flags: needinfo?(nical.bugzilla)
(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.
Attached patch windows-fixSplinter Review
This patch fixes the problem by not using OMTC for these transparent windows.
Assignee: nobody → wmccloskey
Status: NEW → ASSIGNED
Attachment #8375049 - Flags: review?(matt.woodrow)
Attachment #8375049 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/mozilla-central/rev/f78468f352e4
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
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
I'm wondering whether this is another instance of AMD cards not getting along with OMTC.
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
Gary, please open a new bug.
Depends on: 973071
Blocks: 973035
See Also: 966906
Reproduced in Nightly 2014-01-27, Win 7 x64 while switching tabs.
Verified fixed FF 31 RC 2.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.