User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0 Build ID: 20121013030542 Steps to reproduce: I go to https://developer.mozilla.org/media/uploads/demos/p/a/paulrouget/8bfba7f0b6c62d877a2b82dd5e10931e/hacksmozillaorg-achi_1334270447_demo_package/HWACCEL/ and launch the test Actual results: FF16.0.1 60+ FPS FF19.0a1 (2012-10-12) 5FPS Expected results: to have 60+ FPS with OMTC

linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

I don't notice any slowdown, I get 60 fps. Graphics Adapter Description X.Org -- Gallium 0.4 on AMD BARTS Device ID Gallium 0.4 on AMD BARTS Driver Version 3.0 Mesa 9.1-devel GPU Accelerated Windows 0/1 Basic no information WebGL Renderer no information Vendor ID X.Org AzureCanvasBackend cairo AzureContentBackend none AzureFallbackCanvasBackend none

@ Ernst Sjostrand I don't think you have OMTC because: "GPU Accelerated Windows 0/1 Basic no information" See to active OMTC: https://mozillagfx.wordpress.com/2012/10/06/how-to-help-testing-off-main-thread-compositing/

When I run with layers.force-enabled it says 1/1, but when I export MOZ_USE_OMTC=1 I get that instead. The blog post doesn't specify anything that shows OMTC on/off unfortunately.

See bug 798786 for the about:support weirdness when OMTC is on. Actually, that "Basic no information" stuff is probably a sign that OMTC is actually enabled. ;-)

Yes that's because to the content/main thread we're drawing the page using software. The fact that the compositor is hardware accelerated is completely transparent to content.

I got the same behavior on Linux (openSuse 12.1 w/ radeon) between FF 16.0.1 and 19.0a1 (2012-10-15). I go from 8fps in the stable version to 3fps with the nightly and OMTC enabled.

(In reply to Adrien CLERC from comment #7) > I go from 8fps in the stable version to 3fps with the nightly and OMTC > enabled. (In reply to Adrien CLERC from comment #8) > Created attachment 671744 [details] Unfortunately this demo uses ridiculously huge images (640x7760) that are not directly supported on older hardware and therefore not accelerated. (In reply to Benoit Girard (:BenWa) from comment #6) > Yes that's because to the content/main thread we're drawing the page using > software. For GPUs that can handle textures of this size, X11 basic layers are GPU accelerated.

Test with Firefox Nightly 24.0a1 (2013-05-19) and Mesa 9.2.0 (git-639d0f7 precise-oibaf-ppa) Result: 7 fps

For me the test is fast with OMTC when skiagl is also in use. with parameters: layers.offmainthreadcomposition.enabled;true gfx.canvas.azure.backends;skia gfx.canvas.azure.accelerated;true FF24.0a1 no omtc, cairo 9fps FF24.0a1 no omtc, skia 6fps FF24.0a1 no omtc, skiagl 8fps FF24.0a1 omtc, cairo 6fps FF24.0a1 omtc, skia 6fps FF24.0a1 omtc, skiagl 48fps

After an udpate to Linux 3.8 and Mesa 9.1.4 60 + FPS with Firefox 24: Description de la carte Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile Fenêtres avec accélération graphique 0/1 Basic ID du périphérique Mesa DRI Intel(R) Ironlake Mobile ID du vendeur Intel Open Source Technology Center Rendu WebGL Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile Version du pilote 2.1 Mesa 9.1.4 windowLayerManagerRemote false AzureCanvasBackend cairo AzureContentBackend none AzureFallbackCanvasBackend none 22 FPS with Firefox Nightly 27.0 Description de la carte Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile Fenêtres avec accélération graphique 1/1 OpenGL ID du périphérique Mesa DRI Intel(R) Ironlake Mobile ID du vendeur Intel Open Source Technology Center Rendu WebGL Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile Version du pilote 2.1 Mesa 9.1.4 windowLayerManagerRemote false AzureCanvasBackend cairo AzureContentBackend none AzureFallbackCanvasBackend none AzureSkiaAccelerated 0 layers.offmainthreadcomposition.enabled => false It's better

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".

With layers.acceleration.force-enabled - enabled around 17 fps With layers.acceleration.force-enabled - disable 60+fps Card - Nvidia GT-525M, Optimus Enabled(Bumblebee), Fedora 20 ,Firefox: 35.0a1 (2014-09-21)

With layers.acceleration.force-enabled - enabled around 24 fps With layers.acceleration.force-enabled - disable 60+fps Intel HD3000(SandyBridge), Fedora 21, Mesa 10.5.0-devel, Firefox 37.0a1 (2014-12-12)

With layers.acceleration.force-enabled true: ~37 fps With false: 60+ (or so the web page says) Cairo backend, Intel HD Graphics 4000, Ubuntu 15.10, Driver Version 3.0 Mesa 11.0.2, Firefox 43.0a2 20151026004023

(In reply to Dmitry Gutov from comment #16) > With layers.acceleration.force-enabled true: ~37 fps > With false: 60+ (or so the web page says) > > Cairo backend, Intel HD Graphics 4000, Ubuntu 15.10, Driver Version 3.0 Mesa > 11.0.2, Firefox 43.0a2 20151026004023 I have a Lenovo x230 which closely matches this configuration. Could you please tell me if this is Ubuntu 32-bit or 64-bit so I can test this more accurately?

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #17) > Could you > please tell me if this is Ubuntu 32-bit or 64-bit so I can test this more > accurately? It's 64-bit. The CPU is i7 3630QM. And, if that matters anything, the above results were obtained with my usual Firefox profile (not a bare one).

(In reply to Dmitry Gutov from comment #18) > (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #17) > the above results were obtained with my usual Firefox profile (not a bare one). So you cannot reproduce this in a new profile then? If so, testing this on my laptop might be pointless. Could you attach a copy of your about:support page to this bug report?

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #19) > So you cannot reproduce this in a new profile then? I didn't say that. Tried it in a new profile now, and got exactly the same results. Let me know if you need my about:support output.

(In reply to Dmitry Gutov from comment #20) > Tried it in a new profile now, and got exactly the same results. Okay thanks, that's good to know. > Let me know if you need my about:support output. Yes, please do.

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #21) Here you go.

Here is my system info: * Ubuntu 15.10 64-bit * OpenGL 3.0 Mesa 11.0.2 * Cairo backend * Intel Core i7-3520M CPU @ 2.90GHz x4 Here are my results: > Firefox 41.0.2: 60+ fps [OMTC ON] vs 60+ fps [OMTC OFF] > Firefox 42.0b9: 60+ fps [OMTC ON] vs 60+ fps [OMTC OFF] > Firefox 43.0a2: 60+ fps [OMTC ON] vs 60+ fps [OMTC OFF] (e10s ON) > 60+ fps [OMTC ON] vs 60+ fps [OMTC OFF] (e10s OFF) > Firefox 44.0a1: 55 fps [OMTC ON] vs 49 fps [OMTC OFF] (e10s ON) > 60+ fps [OMTC ON] vs 60+ fps [OMTC OFF] (e10s OFF) The only situation where I saw degraded performance was Firefox 44.0a1 with e10s enabled and turning OMTC off actually degraded performance further in this scenario. Even still the degraded performance was still within an acceptable range. I would say that my system probably is not able to reproduce this bug as described although I'm not sure what the differentiating factor is. I suppose the fact that this is a brand new Ubuntu installation could have something to do with it but I really do not know.

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #23) > 60+ fps [OMTC ON] vs 60+ fps [OMTC OFF] I'm not sure we're talking about the same thing. As I understand it, layers.acceleration.force-enabled, which I and some previous commenters experimented with, switches between Basic OMTC and GL-accelerated OMTC. Maybe a better title for this bug would be "[OMTC Linux] Slower with hardware acceleration enabled". > I would say that my system probably is not able to > reproduce this bug as described although I'm not sure what the > differentiating factor is. I suppose the fact that this is a brand new > Ubuntu installation could have something to do with it but I really do not > know. Indeed, my system is fairly old, and has survived several distro upgrades. Will you post your glxinfo output? I'm posting mine.

(In reply to Dmitry Gutov from comment #24) > I'm not sure we're talking about the same thing. As I understand it, > layers.acceleration.force-enabled, which I and some previous commenters > experimented with, switches between Basic OMTC and GL-accelerated OMTC. layers.acceleration.force-enabled is false by default. Turning it on the FPS on Nightly drops further to 43 FPS so it seems like that is also a factor. > Will you post your glxinfo output? I'm posting mine. I did a diff between your glxinfo and mine, they are identical except for some of the more technical bits which I don't understand. https://pastebin.mozilla.org/?diff=8850696 (yours is the +, mine is the -).

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #26) > layers.acceleration.force-enabled is false by default. Turning it on the FPS on Nightly drops further to 43 FPS so it seems like that is also a factor. Good, then our systems are in agreement. It's the *only* factor in my case. Like described in my first comment, I get 60+ with it off (default), and 37 or so with it on. Disabling OMTC itself doesn't seem to work, by the way: even if I set layers.offmainthreadcomposition.enabled to false, "GPU Accelerated Windows" in about:support still says "0/1 Basic (OMTC)". And I get the same 60+ FPS in the test. > I did a diff between your glxinfo and mine, they are identical except for > some of the more technical bits which I don't understand. > https://pastebin.mozilla.org/?diff=8850696 (yours is the +, mine is the -). Thanks. The difference is too technical for me as well.

[Tracking Requested - why for this release]: Did some further testing with layers.acceleration.force-enabled set to true: > Firefox 17: 60 fps > Firefox 18: 20 fps > Firefox 19: 21 fps > Firefox 41: 39 fps > Firefox 44: 43 fps Based on these results it would appear that we regressed performance starting in Firefox 18 and while performance has nearly doubled since then we're still about 30% off. I'll see if I can regress this further but it's going to be extremely difficult given this is 3 years old.

Last Good: Firefox 18.0a1 2012-09-05 [6705e131aeaa] First Bad: Firefox 18.0a1 2012-09-06 [0c4fa25f637b] http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6705e131aeaa&tochange=0c4fa25f637b

So I guess it's: Anthony Jones — Bug 773460 - Change the default canvas over to Azure; r=nrc There's also Marco Castelluccio — Bug 788042 - Use MOZ_X11 instead of MOZ_WIDGET_GTK2 under gfx/layers. r=karlt

(In reply to Ernst Sjostrand from comment #30) > So I guess it's: > Anthony Jones — Bug 773460 - Change the default canvas over to Azure; r=nrc > > There's also > Marco Castelluccio — Bug 788042 - Use MOZ_X11 instead of MOZ_WIDGET_GTK2 > under gfx/layers. r=karlt Anthony and Marco, could you please have a look at this bug?

With: gfx.xrender.enabled false layers.acceleration.force-enabled true gfx.canvas.azure.accelerated true gfx.canvas.azure.backends skia gfx.content.azure.accelerated true gfx.content.azure.backends skia I get 60+ at 4K resolution with Mesa graphics.

(In reply to Ernst Sjostrand from comment #32) Seeing similar results here (but I don't use a 4K resolution). Changing the backends to skia gives me 44 FPS. Adding the *.azure.accelerated properties (they're not there by default) brings it up to 59 (tested these settings two times). gfx.xrender.enabled, on or off, doesn't make any visible difference. Note that this is still slower than with layers.acceleration.force-enabled false, according to the benchmark. In that case I get consistent 60+ FPS.

I think bug 773460 is more likely to have caused a perf regression, but I admit I don't remember what was the purpose behind bug 788042 (I should have written something in its first comment!).

Using HWACCEL test at top + my setup x86_64 ARCH Linux + Radeon 6850HD using OpenSource Drivers on 1080p screen Firefox Nightly v45a1 Azure*Backends=Cairo + CairoUseXRender=1 -> 60+ FPS Azure*Backends=Cairo + CairoUseXRender=0 -> 11 FPS Azure*Backends=Cairo + CairoUseXRender=1 + E10 MultiProcessing ->7 FPS Azure*Backends=Cairo + CairoUseXRender=0 + E10 MultiProcessing -> 11 FPS Azure*Backends=Cairo + CairoUseXRender=1 + Layers Force Acceleration -> 6 FPS Azure*Backends=Skia + AzureSkiaAccelerated=0 -> 13 FPS Azure*Backends=Skia + AzureSkiaAccelerated=1 -> 13 FPS Azure*Backends=Skia + AzureSkiaAccelerated=1 + Layers Force Acceleration -> 12 FPS Azure*Backends=Skia + AzureSkiaAccelerated=1 + Layers Force Acceleration + E10 MultiProcessing -> 16 FPS So only cairo + xrender give me proper 60+ result.

(In reply to Erdem U. Altinyurt from comment #35) > So only cairo + xrender give me proper 60+ result. Isn't that the default?

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #36) > (In reply to Erdem U. Altinyurt from comment #35) > > So only cairo + xrender give me proper 60+ result. > > Isn't that the default? Depends, A.F.A.I.K. since E10 is activated by default. Azure*Backends=Cairo + CairoUseXRender=1 + E10 MultiProcessing ->7 FPS

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #36) > Isn't that the default? Isn't the point of this bug to discuss why the default is what it is, and how that can be improved? I.e. no HW acceleration for layers in Linux.

41 was EOL'd last week. This is now a wontfix for FF41.

(In reply to Dmitry Gutov from comment #38) > (In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #36) > > > Isn't that the default? > > Isn't the point of this bug to discuss why the default is what it is, and > how that can be improved? I.e. no HW acceleration for layers in Linux. Just checking that nothing is broken. IIUC resolving this bug depends on bug 627699.