978282 - Elements Rendered as Black Rectangles

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Sean Stangl [:sstangl]]

Attachment: Facebook with overlays active

First noticed on the 2/27 Nightly, but also reproduces with 2/28. Random interface elements (new tabs, the URL preview in the lower-right corner) are rendered as black rectangles, but I couldn't find any STR.

However, Facebook's overlays are always rendered as black rectangles. To reproduce, I need to log in and click the "planet" icon in the top-right corner.

The attached screenshot is unredacted and shows what Facebook actually looks like on my screen once I toggle the overlay.

Also, while writing this, the text just turned black and I can't see what I'm typing any longer.

I have layers.acceleration.force-enabled as "true", webgl.disabled as "true", and the following graphics information:

Adapter Description: nouveau -- Gallium 0.4 on NVC1
Device ID: Gallium 0.4 on NVC1
Driver Version: 3.0 Mesa 9.2.5
GPU Accelerated Windows: 1/1 OpenGL (OMTC)
Vendor ID: nouveau
windowLayerManagerRemote: true
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

Comment 1

[Robert Kaiser]

(In reply to Sean Stangl [:sstangl] from comment #0)
> I have layers.acceleration.force-enabled as "true"

I think that's what makes the difference. I have that and OMTC activated in my Firefox Nightly and I'm seeing this, e.g. the graph on https://crash-stats.mozilla.com/home/products/Firefox is completely black - in other places a frame is rendered as a black square and then a few seconds later replaced by a correct rendering.

On the SeaMonkey trunk builds that I compile as well, I do not have acceleration or OMTC turned on and things always render correctly.

In my case that's with the following info in about:support on Firefox Nightly:

Adapter Description: Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Desktop
Device ID: Mesa DRI Intel(R) Sandybridge Desktop
Driver Version: 3.0 Mesa 10.0.3
GPU Accelerated Windows: 5/5 OpenGL (OMTC)
Vendor ID: Intel Open Source Technology Center
WebGL Renderer: Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Desktop
windowLayerManagerRemote: true
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

As a comparison, those values are the differences in SeaMonkey's info:

GPU Accelerated Windows: 0/2 Basic
windowLayerManagerRemote: false

Comment 2

[Robert Kaiser]

Bug 973035 is possibly related to this.

Comment 3

[Bill Gianopoulos [:WG9s]]

(In reply to Robert Kaiser (:[e-mail]) from comment #2)
> Bug 973035 is possibly related to this.

I don;t believe it is.  The reporter of that bug had AMD/ATI graphics.  I only see this bug with Intel Sandybridge.  I do not see on any of my AMD/ATI systems, or the one with NVIDIA graphics.

Comment 4

[Bill Gianopoulos [:WG9s]]

hg bisect identified:

The first bad revision is:
changeset:   170584:5ae2a4860eca
user:        Matt Woodrow <[e-mail]>
date:        Sat Feb 22 22:22:43 2014 +1300
summary:     Bug 974709 - Use a separate texture for each X11TextureSource and keep the pixmap bound. r=nical

Comment 5

[John Schoenick [:johns]]

Possibly duplicate of bug 977963

Comment 6

[Bill Gianopoulos [:WG9s]]

I verified that backing out bug 974709 avoids this issue for me.

Comment 7

[Bill Gianopoulos [:WG9s]]

(In reply to Bill Gianopoulos [:WG9s] from comment #3)
> (In reply to Robert Kaiser (:[e-mail]) from comment #2)
> > Bug 973035 is possibly related to this.
> 
> I don;t believe it is.  The reporter of that bug had AMD/ATI graphics.  I
> only see this bug with Intel Sandybridge.  I do not see on any of my AMD/ATI
> systems, or the one with NVIDIA graphics.

Ignore my comment here.  It turns out that I don;t see the issue I do on Gmail, which is what I was using for the bisect on my system with AMD/ATI graphics.  However, it has black all over the place on Facebook.  Backing out bug 974709 fixes the AMD/ATI black on Facebook issue also.

Comment 8

[Bill Gianopoulos [:WG9s]]

Oh I still do not see this issue at all on my system that has Nvidia graphics.

Comment 9

[Robert Kaiser]

(In reply to Bill Gianopoulos [:WG9s] from comment #8)
> Oh I still do not see this issue at all on my system that has Nvidia
> graphics.

Note that this bug has been reported initially on an NVidia-powered system, but with the open drivers (nouveau/Gallium3D) and not the proprietary/binary ones.
Of course, it looks like you need to make sure that OMTC is actually enabled or you will not see the issue. If I turn off OMTC, things are fine here as well.

Comment 10

[Bill Gianopoulos [:WG9s]]

I see the bug here with OMTC disabled, and layers acceleration force-enabled under AMD/ATI graphics.  So, if 973035 is OMTC only, I would guess that is a different issue but same symptoms.

Also, bug 973035 was reported on Feb 14th, and the regression bug here did not land until Feb 27th.

Comment 11

[Robert Kaiser]

Well, all the about:support info posted here and on bug 973035 says OMTC in "GPU Accelerated Windows", but it might very well only be acceleration.

The landing of bug 974709 at least matches the time of my regression pretty much, from what I remember. It's entirely possible that bug 973035 can be a different issue, of course. Note that in comment #2 I only said *possibly related*, if I would have taken for granted that it was the same thing, I would have marked one as a dupe of the other. ;-)

Comment 12

[Bill Gianopoulos [:WG9s]]

The pending patch on Bug 977963 avoids this issue.

Comment 13

[u279076]

Does this still reproduce?

Comment 14

[Sean Stangl [:sstangl]]

Not since 2014!