In recent nightly, changing gfx.content.azure.backends and gfx.content.canvas.backends to skia results in major performance improvements (especially in WebGL), and in regular browsing I've encountered no crashes or rendering glitches. It works, and it works well. I suggest these settings should be default for Linux. In addition, I've tried setting layers.offmainthreadcomposition.enabled to true and layers.acceleration.force-enabled to true, and it also improved performance a bit with no problems encountered, so I suggest these should be default for Linux too - at least when running recent mesa. Relevant graphics info from about:support Adapter Description X.Org -- Gallium 0.4 on AMD CAPE VERDE Device ID Gallium 0.4 on AMD CAPE VERDE Driver Version 3.0 Mesa 10.2.3 GPU Accelerated Windows 1/1 OpenGL (OMTC) Vendor ID X.Org WebGL Renderer X.Org -- Gallium 0.4 on AMD CAPE VERDE windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend skia AzureFallbackCanvasBackend none AzureSkiaAccelerated 0 Running on Fedora 21, using the nightly build from Mozilla.

We all want these three things, but they are not completely ready yet: Skia on Linux is tracked in bug 740200 OMTC on linux is tracked in bug 722012, but will first land without acceleration (tracked by bug 994541) As far as hardware layers acceleration is concerned, there's a lot of testing to do on a lot of hardware, some driver blacklisting to do, etc.

Skia is the major performance improvement for me, the others are just bonuses. I see the bug is closed, but Skia is still not default on linux. The only bug it has blocking it that is still open seems to be gone in Nightly. So, why isn't Skia enabled by default?

(In reply to Elad Alfassa from comment #2) > Skia is the major performance improvement for me, the others are just > bonuses. I see the bug is closed, but Skia is still not default on linux. > The only bug it has blocking it that is still open seems to be gone in > Nightly. So, why isn't Skia enabled by default? My bad this was the bug to get skia to "work" but there are more things to do for it to pass all reftests and handle things like native theme drawing and plugins: Bug 996611, Bug 939709, Bug 996611, Bug 738937, Bug 720523.

I'm not sure if it's just me but only the skia canvas backend works fine, if I set the content one to skia, I get artefacts/corruption, mostly around tabs. Same if I enable OMTC.

It is not just you. That is the state we are in right now; once the dependent bugs of this one are fixed, those issues should go away.

(In reply to Elad Alfassa from comment #2) > Skia is the major performance improvement for me, the others are just > bonuses. OMTC work is not superfluous here because right now, OGL layers are being grandfathered OMTC on linux. See : http://lxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#2028

http://inspirehep.net/author/profile/G.Grunberg.1 (page that was pathologically broken in Firefox) http://m8y.org/tmp/testcase432.xhtml (breakout of the insanity that was breaking Firefox) I don't think Layers Acceleration is totally stable on my machine, unfortunately, so not the best solution... (01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730 XT [Radeon HD 4670] + radeon driver) Also, while switching those on fixes the unusability of the browser and X, my CPU usage goes up a lot. 971 nemo 20 0 787336 186624 52008 S 102.0 1.1 5:11.13 Web Content 28433 nemo 20 0 1354216 273852 62692 S 52.2 1.7 524:00.94 firefox Anyway, +1 for anything that helps avoid Firefox freezing up entirely and making X session semi-unusable on stupid pages like that one.

BTW, on subject of enabling skia... Setting azure on content to skia causes ugly banding on http://m8y.org/tmp/testcase429.xhtml (which has a few performance issues mentioned in bug #1156772 - especially on OSX)

(In reply to nemo from comment #8) > BTW, on subject of enabling skia... Setting azure on content to skia causes > ugly banding on http://m8y.org/tmp/testcase429.xhtml (which has a few > performance issues mentioned in bug #1156772 - especially on OSX) I see NO banding here... Just smooth transition. User Agent Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 Version 41.0b2 Adapter Description NVIDIA Corporation -- NVS 510/PCIe/SSE2 Asynchronous Pan/Zoom none Device ID NVS 510/PCIe/SSE2 Driver Version 4.5.0 NVIDIA 355.06 GPU Accelerated Windows 1/1 OpenGL (OMTC) Supports Hardware H264 Decoding false Vendor ID NVIDIA Corporation WebGL Renderer NVIDIA Corporation -- NVS 510/PCIe/SSE2 windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend skia AzureFallbackCanvasBackend none AzureSkiaAccelerated 0

Ops... its somehow got broken after tabs switching. Sorry.

Heh. Maybe you forgot to restart. Also, FWIW, I reenabled skia in nightly and CPU usage on that testcase shot through the roof, such that Firefox was burning almost as much CPU as Chrome. Cairo appears to be a lot more efficient on that case right now, as well as rendering nicer. https://bugzilla.mozilla.org/show_bug.cgi?id=1168879

I tossed my CPU consumption on that testcase onto the bug for the banding in the testcase. But basically it was ~185% in Chromium, ~95% in Firefox with Skia, and ~17% in Firefox with Cairo.

Oh, just for the heck of it. Tried on my coworker's machine... Firefox Stable, 5% CPU (but he was running a bunch of other tabs sooooo) Internet Explorer 11 0% CPU (!) Chrome, 60% CPU (and ugly banding) This might be moderately related to your fix if the fix worsens the already not-great situation here?

Oh, um, minor bug so probably spamming it isn't too much of a problem, but just to be clear for friends that I link to this. That CPU usage in Windows was against a totally different machine with a different graphics card, different Firefox version (stable versus nightly) and without taking into account any operating system CPU such as Xorg in the case of my Linux machine.

I have problems with canvas text rendering when canvas skia enabled (bug 1261699).

It works for me, using Firefox 46 with GTK3. Here are the keys that I enabled: layers.acceleration.force-enabled = true gfx.canvas.azure.backends = skia gfx.content.azure.backends = skia gfx.canvas.azure.accelerated = true

Shmerl, great - if you run into any problems, please open new bugs and link them to "block" this one. We're not quite ready to turn this on by default for everybody, but if it works for you, keep it on and let us know if you find into any problems specific to this configuration. It will help us eventually enable it by default for everybody.

I can't update the blockers but please don't make skia the default on Linux until the CPU issues can be fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=1168879 https://bugzilla.mozilla.org/show_bug.cgi?id=1156772

WRT comment #18 As much as I love using CSS gradient animations for fun effects... to be fair, while skia and chrome have been total crap in terms of rendering and CPU on that effect, good old compiz has sucked on other things too. I ran into this insane "HTML5" spinner that utterly froze up compiz. http://m8y.org/tmp/testcase432.xhtml It's hard to say, but I'm going to WAG it'll be a net win to enable it by default. Just because, well, frankly, thanks to google's relentless promotion, people design for chrome by default, and thus ensure things are fast on chrome. Using skia for rendering will at least bring into line with this, just as if Firefox were rendering w/ IE's graphics layer way back when MS used their muscle. (speaking above as a fanboi, and not at all linked to Mozilla in any way ofc ☺ )

... uh. cairo. not compiz. sorry. my brain mixed up "graphics-related projects beginning with c"

Hmm.. well that page definitely causes high CPU for me (with cairo backend) when the tab is in the foreground (CPU goes down when I switched to this tab). But I was able to type and use my PC (5+ year old sandybridge core-i5) just fine. I just bumped this bug this morning because I saw the other CPU issues and had noticed them when testing skia, and was hoping that before skia became the default (and/or cairo was removed) that the latest skia was imported and as much work reducing CPU could be done.

Was the latest Skia imported into Firefox and will they continue to track it?

We are not too far behind, but we are not on "nightly" Skia. Next round of updates will happen in April timeframe, to what is then a release candidate for Skia.

What's the status here? Is this bug still being followed?

Skia and OMTC are enabled, opengl compositing is not (and nobody is working on it at the moment).

(In reply to Nicolas Silva [:nical] from comment #25) > opengl compositing is not [enabled](and nobody is working > on it at the moment). Is it because of increased focus on webrender (https://github.com/servo/webrender/wiki) which is intended to replace current approach, or simply because Linux is not a priority?

Not finding time to focus on it, to at least whitelist the system where things work fairly well. You may recall we had the acceleration on nightly for a while, and then ran out of resources to resolve the critical problems on some systems, and identify the ones that work, and disabled it again.