1151749 - Win-Only: Disabled Hardware Acceleration + CSS 3D transform on canvas -> black artefacts on hover

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[rototor]

Attachment: Black Artefacts on Hover

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36

Steps to reproduce:

If your PC happens to have working hardware acceleration, disable it in the settings and restart firefox. Visit

https://www.myprintcard.de/hochzeitskarten/hochzeitseinladungen/editor-quadratischklapp-mitfoto-1cl7?showbug

Click on the text "Einladungen", and then hover over the text aligment buttons. The hovered buttons get repainted as black rectangles. Resize the window or scroll, and everything is fine again. See the attached screenshot for an example.

This sometimes even affects the Firefox chrome in the current Firefox stable. In Firefox Nightly the chrome is not affected - i think because it currently tests Process Seperation. (The black artefacts are still there in Firefox Nightly)

I first reproduced this problem using a VirtualBox modern.ie VM, but i was able to reproduce this on real windows boxes with hardware acceleration disabled.

I tried to build a simple jsfiddle for this problem, but i was not able to create a simple testcase, which triggers the problem. The "overview screen" on the bottom uses 3d transforms on canvas elements. This causes the problem. If the 3d transform is not used, the problem disappears.


Actual results:

Black artefacts, see the screenshot.

This problem only happens on Windows, and only if hardware acceleration is disabled. Works fine on Windows with hardware acceleration enabled, works fine on Mac with/without hardware acceleration, same on Linux. All other browser (Safari, IE, Chrome) also dont have this problem.

Seems like some kind of "draw with invalid bitmap handle" race to me.

Note: I implemented a workaround for this problem. When the browser is Firefox on Windows and WebGL is not possible, no 3d transform is used. To force the usage of 3d transform you have the specify a "showbug" parameter in the url. (As given in the example URL).

Detecting WebGL is currently the best way i know to detect if hardware acceleration is on. Is there any other way to detect hardware acceleration? If the user has WebGL, but disabled the hardware acceleration, i have currently no way to detect this - in this case the user sees this black artefacts :(


Expected results:

There should not be any black artefacts.

Please tell me if I can help in any way to debug/fix this problem. I´m willing to make a local debug build of Firefox and try to debug this. You just need to give me some pointers where to look. Thanks.

Comment 1

[rototor]

I did a fresh debug build of Firefox. I get this errors in the console log when hovering over the buttons:

[Parent 1076] WARNING: '!temp', file c:\mozilla-source\mozilla-central\gfx\layers\basic/BasicCompositor.cpp, line 457
[GFX3-]: Surface width or height <= 0!
[GFX3-]: Surface width or height <= 0!
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to allocate a surface due to invalid size Size(1,0)|[246][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[242][GFX1-]: Failed to allocate a surface due to invalid size Size(1,0)|[243][GFX1-]: Failed to allocate a surface due to invalid size Size(1,0)|[244][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[245][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)[GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)
[Parent 1076] WARNING: '!temp', file c:\mozilla-source\mozilla-central\gfx\layers\basic/BasicCompositor.cpp, line 457
[GFX3-]: Surface width or height <= 0!
[GFX3-]: Surface width or height <= 0!
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Fai[Palrenet 1d076 ] WtARNoING : Parevliouls ovsycnc atimtesteamp  isa ah eads ofu thre cfalcaulactede vs yncd timuesteamp .: tfiol e ic:/nmozvillaa-slourice/dmo zilsla-icenztrael/g fx/Stheibesz/gfexWi(ndo1wsP,lat0for)m.c|pp,[ li2ne 421362
][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[247][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[243][GFX1-]: Failed to allocate a surface due to invalid size Size(1,0)|[244][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[245][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)[GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)
[Parent 1076] WARNING: '!temp', file c:\mozilla-source\mozilla-central\gfx\layers\basic/BasicCompositor.cpp, line 457
[GFX3-]: Surface width or height <= 0!
[GFX3-]: Surface width or height <= 0!
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to allocate a surface due to invalid size Size(1,0)|[246][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[247][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[248][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[244][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)|[245][GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)[GFX1-]: Failed to allocate a surface due to invalid size Size(0,1)

I dont know if this causes the black artefacts, or if this is unrelated.

Comment 2

[rototor]

Attachment: basiccompositor_popclip_on_not_temp.patch

While trying to understand whats going on here i found that buffer->PopClip() is not called if the allocation of the surface does not succeed. Didnt fix this problem, but might still be a bug. 

The transformBounds have a size of 0/0 here. Is something wrong with the transformation matrix?

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Comment on attachment 8589094 [details] [diff] [review]
basiccompositor_popclip_on_not_temp.patch

Nical, can you review this?

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=aaefef23647f

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/48ea157bc34f

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/48ea157bc34f

Comment 7

[rototor]

Thanks for commiting this obvious one line fix. But as I already wrote, this does not fix the bug. Just verified with the latest nightly build. It seems to me you did not read the bug description, did you?

I see that you are all very busy, so am I. But could you at least give me some pointers where to look?

I dont know the Firefox code base and inner workings, but I suspect that the following is happining here:

 - hover repaints try to minimize the repainted areas, and don´t repaint everything.
 - somehow the "outer matrix/gfx state" is not reset correctly after a full repaint, and still contains state from the 3D transform.
 - the hover then uses this to repaint the hovered areas, cleares them with black but then does paint nothing because of the wrong transform matrix.

The one liner you commited fixes just a "follow up" bug, which happens because the matrix is wrong (and leads to a 0x0 bitmap, which cant be painted).

Please give me some advice where to look further. Thanks.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Sorry about that, I failed to put the "leave open" on the bug, so once your fix made it in, it got magically closed.
I'm not seeing this on the latest beta, with acceleration disabled, but WebGL available (e.g., my about:support shows Basic(OMTC) for GPU Accelerated Windows, cairo as content backend, and an ANGLE Intel string for WebGL Renderer.)  What's your about:support look like?  I do get the "invalid size" (0,1) messages, but not the black squares.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Given that I can't reproduce, I wonder if we're "just" running into bug 1072898.

Comment 10

[rototor]

Milan, I tried to reproduce this bug with the latest nightly (28-04-2015) and can no longer reproduce it. With the one from 27-04-2015 the bug still happened, and with Firefox stable 37.0.2 the bug is also reproducible. So some change of yesterday fixed this bug. Maybe even this one line patch, and I was to stupid to rebuild firefox correctly...

Thanks, this works for me now.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

\o/

Comment 12

[arni2033]

This was clearly "Fixed". Thanks a lot for the fix btw.