Closed
Bug 1151644
Opened 9 years ago
Closed 9 years ago
Window renders blank with layers.acceleration.disabled set to true
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
VERIFIED
FIXED
mozilla40
Tracking | Status | |
---|---|---|
firefox37 | --- | unaffected |
firefox38 | --- | unaffected |
firefox39 | --- | verified |
firefox40 | --- | verified |
People
(Reporter: u279076, Assigned: nical)
References
Details
(Keywords: regression, Whiteboard: gfx-noted)
Attachments
(2 files)
1.15 KB,
patch
|
jrmuizel
:
review+
lmandel
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
8.35 KB,
text/plain
|
Details |
In a recent Nightly we regressed Layers. The window just renders blank if layers is disabled on Mac. I've traced this back to the following window on mozilla-central. Last Good: 2015-03-26 [37d3dcbf23a9] First Bad: 2015-03-27 [e046475a75cb] Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37d3dcbf23a9&tochange=e046475a75cb I'll try to regress this further. [Tracking Requested - why for this release]: this is a pretty serious usability regression for people with Layers disabled.
Keywords: regression,
regressionwindow-wanted
Tinderbox regression window =========================== Last Good: 20150325130909 [f40ee067d081] First Bad: 20150325165811 [37d3dcbf23a9] https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40ee067d081&tochange=37d3dcbf23a9
Keywords: regressionwindow-wanted
Comment 2•9 years ago
|
||
Does this bug have anything to do with the rendering mixing up content when scrolling? I think that regression started for me by the end of March. Since then I'm on Aurora but since the upgrade to 39a2 I've the same problems again.
(In reply to Tim Kuijsten from comment #2) > Does this bug have anything to do with the rendering mixing up content when > scrolling? As far as I can tell this is nothing to do with scrolling as the bug happens immediately on startup without any user interaction whatsoever.
Comment 4•9 years ago
|
||
I have reproduced this bug on OSX but it does not appears to affect Linux.
Comment 5•9 years ago
|
||
Possibly a dup of bug 1151492.
Comment 6•9 years ago
|
||
Currently I have the same problem with nightly, complete white page, white dialogs, not usable at all. The artifacts that show up when scrolling as I've reported earlier is what I currently experience with 39a2 and previously with 39a1 (it made me downgrade from 39a1 to 38a2 at the time).
Tim, you should be able to work around this by setting layers.acceleration.disabled to false in about:config. If there is some other reason you need to keep Layers disabled then my recommendation would be to switch to Dev Edition until this is resolved.
Comment 8•9 years ago
|
||
That indeed does the trick. I've heard some rumor about some security risks that might come with hardware acceleration. That's the reason I've disabled it but I haven't been able to really find out if this is true or what this claim is based upon. For now I'm on Dev.
I am not aware of the security risks you mention but I'm also not a technical expert on this feature. If you have serious concerns I would recommend you write a post to dev-platform@lists.mozilla.org explaining these concerns so you can get insight directly from the people writing the code.
Comment 10•9 years ago
|
||
Tnx! As soon as I'll see some messages around the topic, I'll contact them.
Don't think the regression range is the correct one, at least comment 0 and comment 1 have conflicting info (notice that the last good from comment 0 is the same change as the first bad from comment 1.) This seems to be it for me, but only if I have "Use hardware acceleration when available" disabled; in other words, when bug 1151491 kicks in. https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da2f28836843&tochange=e5b72a8edb82 In particular, bug 1125848. So, the question is, do others see this problem when "Use hardware acceleration when available" is left at the default value of enabled?
Whiteboard: gfx-noted
So, it looks like the third (not uplifted) patch to bug 1125848 broke the basic layers on OS X.
Assignee | ||
Comment 13•9 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #12) > So, it looks like the third (not uplifted) patch to bug 1125848 broke the > basic layers on OS X. Huh, weird. I'll try to get my hand on a mac and debug this. If I don't figure it out in the next few days, I'll back the patch out.
Assignee: nobody → nical.bugzilla
Comment 15•9 years ago
|
||
Bug 1153794 might be a dupe of this. I think h/w acceleration is being disabled by blocking a bad driver, layers.acceleration.disabled is already false and flipping it has no effect.
Assignee | ||
Comment 17•9 years ago
|
||
We are trying to create a compositor with no backend, which inevitably fails. On the client side we go thorugh this: https://dxr.mozilla.org/mozilla-central/source/widget/nsBaseWidget.cpp?from=nsBaseWidget.cpp#1145 Which removes the basic backend from the list of backends (and we end up shipping a list with no backends at all which is just silly). I think that we don't need this logic anymore (it was added back when the basic compositor wasn't usable). It's harmless to remove this now (and removing it fixes the issue). What bug 1125848 has probably caused, is that mRequireOffMainThreadCompositing is false although it should be true, but I haven't yet identified why.
Assignee | ||
Comment 18•9 years ago
|
||
Attachment #8592854 -
Flags: review?(jmuizelaar)
Updated•9 years ago
|
Attachment #8592854 -
Flags: review?(jmuizelaar) → review+
Comment 19•9 years ago
|
||
Comment on attachment 8592854 [details] [diff] [review] stop disallowing the basic backend. I tried this patch on 10.9, and it worked fine. But I then ran the build on an old Mac mini with 10.6.8 (GMA 950 chip) and I still see the issue. I then tried a nightly from 2015-03-30 on the same system and it worked fine. This is the Graphics section from about:support: Asynchronous Pan/Zoom none GPU Accelerated Windows 0/1 Basic WebGL Renderer Apple Computer, Inc. -- Apple Software Renderer windowLayerManagerRemote false AzureCanvasBackend quartz AzureContentBackend quartz AzureFallbackCanvasBackend none AzureSkiaAccelerated 0
Comment 20•9 years ago
|
||
Console output when running on 10.6.8 with intel GMA 950
Comment 21•9 years ago
|
||
Just to clarify: I see the issue regardless of layers.acceleratin.disabled is set to true or false and I access this Mac from the 10.9 machine with Screen sharing.
Comment 22•9 years ago
|
||
This patch worked for me on OSX 10.10.3. My graphics section from about:support: Asynchronous Pan/Zoom none Device ID 0xfe9 GPU Accelerated Windows 0/1 Basic (OMTC) Vendor ID 0x10de WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 750M OpenGL Engine windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend quartz AzureFallbackCanvasBackend none AzureSkiaAccelerated 0
Reporter | ||
Comment 23•9 years ago
|
||
(In reply to Stefan [:stefanh] from comment #21) > Just to clarify: I see the issue regardless of layers.acceleratin.disabled > is set to true or false and I access this Mac from the 10.9 machine with > Screen sharing. Can you confirm if the regression window in comment 0 is relevant for that use case? If not then you might be seeing a different bug with similar symptoms.
Comment 24•9 years ago
|
||
> Can you confirm if the regression window in comment 0 is relevant for that > use case? But is that the right regression window (comment #11)? As I said, it works for me with a nightly from 2015-03-30 and according to comment #12 and looking at bug 1125848, comment #63 this seems to have regressed 2015-04-01. I can check 2015-03-31 and 2015-04-01, though.
Comment 25•9 years ago
|
||
OK, so I checked when it regressed on the 10.6.8 machine (from ftp://ftp.mozilla.org/../pub/firefox/nightly/): Good: 2015-03-31-03-02-04-mozilla-central Bad: 2015-04-01-18-09-20-mozilla-central
Comment 26•9 years ago
|
||
That's what I had in bug 1153794 too, on 10.7.5 with an old machine that is blocklisted from acceleration. Attachment 8592854 [details] [diff] also resolves the problem for me (try build at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/nthomas@mozilla.com-f428e02f6acc/try-macosx64/ if anyone wants it).
Assignee | ||
Comment 27•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/c20a7ab389ff
Comment 28•9 years ago
|
||
Looking at widget/cocoa/GfxInfo.mm, it looks like GMA 950 isn't blocklisted. Perhaps this is a separate issue then. I'll investigate a bit more in a few days (no time until the weekend) - I can file a new bug then.
Comment 29•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c20a7ab389ff
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Comment 31•9 years ago
|
||
Anthony can you verify the fix on 40? It would be good to verify this works before we try uplifting it to 39.
Flags: needinfo?(anthony.s.hughes)
Updated•9 years ago
|
Flags: qe-verify+
Fixed it for me on 40, OS X 10.9.5
Comment 33•9 years ago
|
||
fixed for me :) OS X 10.10.3
Comment 34•9 years ago
|
||
This doesn't work for me with the 10.6.8 machine with GMA 950 and I'm not sure about comment #28 anymore... I tracked down the 10.6.8/GMA 950 regression by using mozilla-inbound tinderbox builds and the first bad build is built from https://hg.mozilla.org/integration/mozilla-inbound/rev/295db120bf12 which is the third patch in bug 1125848. Do you want a new bug for this? I mean it's obviously quite old hardware (I use it for testing patches on 10.6.8).
Assignee | ||
Comment 35•9 years ago
|
||
(In reply to Stefan [:stefanh] from comment #34) > Do you want a new bug for this? I mean it's obviously quite old hardware (I > use it for testing patches on 10.6.8). Yes, that would be good.
Comment 36•9 years ago
|
||
(In reply to Nicolas Silva [:nical] from comment #35) > (In reply to Stefan [:stefanh] from comment #34) > > Do you want a new bug for this? I mean it's obviously quite old hardware (I > > use it for testing patches on 10.6.8). > > Yes, that would be good. Filed bug 1156833.
Comment 37•9 years ago
|
||
Nical - Looks like this fix is good and we'll handle follow up in bug 1156833. 39 is marked as affected. What do you think about uplifting this fix to Aurora?
Flags: needinfo?(nical.bugzilla)
The original patch that regressed this never landed beyond 40, so I'm not convinced 39 is affected, although the problem may have existed there.
Assignee | ||
Comment 39•9 years ago
|
||
Comment on attachment 8592854 [details] [diff] [review] stop disallowing the basic backend. In doubt, the patch is trivial and also correct on aurora. Approval Request Comment [Feature/regressing bug #]: [User impact if declined]: firefox may be unusable for some people on mac with layers acceleration disabled or blacklisted. [Describe test coverage new/current, TreeHerder]: [Risks and why]: Low risk: removes a piece of code that makes no sense any more. [String/UUID change made/needed]:
Flags: needinfo?(nical.bugzilla)
Attachment #8592854 -
Flags: approval-mozilla-aurora?
Comment 40•9 years ago
|
||
Comment on attachment 8592854 [details] [diff] [review] stop disallowing the basic backend. Even though there is some doubt of the need for this uplift, I'd like to take it speculatively. Aurora+
Attachment #8592854 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Reporter | ||
Comment 42•9 years ago
|
||
I confirm this has been resolved in the latest Firefox 40.0a1 and 39.0a2 builds.
Status: RESOLVED → VERIFIED
Flags: needinfo?(anthony.s.hughes)
Comment 43•9 years ago
|
||
Fabulous. Thanks Anthony.
tracking-firefox39:
+ → ---
tracking-firefox40:
+ → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•