image sprite is packed very asymmetrically - triggers poor rendering performance in firefox3 and missing icons in firefox4 and konquerer

[Ralph Corderoy]

Ubuntu 10.10. Viewing a bug, e.g.
https://bugs.launchpad.net/ubuntu/+source/anacron/+bug/606491, is very
slow in Firefox. It's observable in many ways, e.g. scrolling is
extremely sluggish, especially when the top of the page is neared. Even
having the page redraw on an X Expose event takes seconds, e.g. when
Firefox is unminimised with the bug tab selected. The CPU fan audibly
steps. The X server continues to process other clients though during
Firefox's hiatus.

If I adblock just
https://bugs.launchpad.net/+icing/rev12670/icon-sprites then fast snappy
speed is restored. This is a PNG although the HTTP server is specifying
a text/plain content-type.

    $ HEAD https://bugs.launchpad.net/+icing/rev12670/icon-sprites | grep Content-Type
    Content-Type: text/plain
    $ wget -qO- https://bugs.launchpad.net/+icing/rev12670/icon-sprites | file -
    /dev/stdin: PNG image, 64 x 20553, 8-bit/color RGBA, non-interlaced

It is of huge vertical size. A friend reports Webkit also having issues
with the Bug View page using it, but not Opera. Perhaps Firefox and
Webkit hand the huge image onto the X server but Opera cuts out the
sprites itself and hands many small images on. I'm using Nvidia
graphics hardware and did find this comment by an AaronP, an Nvidia
employee.

    http://www.nvnews.net/vbulletin/showthread.php?t=152295#7
    Re: launchpad.net bug views excruciatingly slow

    Thanks for reporting this. I took a look today, and it appears that
    Firefox is using an enormous pixmap that exceeds the GPU's maximum
    rendering dimensions, causing software fallbacks. While we will
    attempt to make it as fast as possible, performance would be greatly
    improved if Firefox would render using surfaces that fit within the
    maximum renderable dimensions.

A brief look at .../rev12670/icon-sprites didn't show up why it's packed
so poorly giving such a large height. The simplest solution may be to
pack the sprites more tightly resulting in a dense squarish image. I
agree with AaronP that perhaps Firefox could cope better but it seems
poor for Launchpad to dish up such a sprite collection.

As it stands, viewing bugs on Launchpad is very frustrating. Every
expose means seconds delay.

See also bug 605567

The khtml engine will not render an png image that exceeds 16,300px. The launchpad sprite is greater than 20,000px. No browser promises to support an image that large. Though this issue currently affects Konqueror, it could effect other browsers because there is no mechanism to ensure the sprites are sensibly sized.

[T-artem (t-artem)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b10) Gecko/20100101 Firefox/4.0b10

Under Linux you cannot scroll the aforementioned URL - scrolling is extremely jerky while Firefox consumes 100% of CPU.

Reproducible: Always

Steps to Reproduce:
Visit the given URL.
Actual Results:
Terribly slow and jerky scrolling.

Expected Results:
Smooth scrolling.

This problem exists both in Firefox 3.6.13 and 4.0beta10 with clean (new) profiles.

Opera 11 and Google Chrome 8 don't exhibit this problem.

[Srinivas (srinivas)]

Mozilla/5.0 (X11; Linux i686; rv:2.0b10) Gecko/20100101 Firefox/4.0b10
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8

Works fine for me

[T-artem (t-artem)]

It's 100% reproducible when running on NVIDIA GPU with NVIDIA proprietary drivers.

[Lemmiwinks (lemmiwinks)]

This is the comment about that bug by AaronP, a Nvidia Linux Driver developer, maybe it helps:
" I took a look today, and it appears that Firefox is using an enormous pixmap that exceeds the GPU's maximum rendering dimensions, causing software fallbacks. While we will attempt to make it as fast as possible, performance would be greatly improved if Firefox would render using surfaces that fit within the maximum renderable dimensions."
Also see: http://www.nvnews.net/vbulletin/showthread.php?t=152295

[George-carstoiu-g (george-carstoiu-g)]

Mozilla/5.0 (X11; Linux i686; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

I was unable to reproduce issue with an integrated Intel card. Can someone having a Nvidia card confirm issue?

[Cleanrock (cleanrock)]

I can confirm this on nvidia.
I am running archlinux, firefox 3.6.13, xorg 1.9.3.901 and nvidia 260.19.36 (on both GTX460 and GT240).
I have seen this for a long time but when i tested it now again i noticed that if i set a non-default zoom level the page is quick, perhaps this can be a hint to someone fixing this annoying performance problem.

[Lemmiwinks (lemmiwinks)]

I can confirm this bug, with my 8600m GT Nvidia proprietary driver version 260.xx - 270.xx, Firefox 3.6 - 4.0, Ubuntu 10.10, although for me it is much more obvious on this URL: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

I can also confirm that changing the zoom level to a non default one makes it much better or even go away completely.

[T-artem (t-artem)]

NVIDIA 8800GT, 270.18 drivers, no matter which zoom level is set, page scrolling is very slow and jerky.

[Henrik Nyberg (henrik-mysko)]

I can confirm this problem as well, on a NVIDIA 8800GT using the 260 and 270 drivers at least, but it has existed prior to them as well, as far as I know.

However the nouveau driver seems to handle the page just fine. Could it not be a driver problem after all?

[George-carstoiu-g (george-carstoiu-g)]

Thank you for being so fast in verifying this issue.

Can you please test problem having the latest nvidia official drivers installed, just to make sure it's not driver related.

[Cleanrock (cleanrock)]

I am pretty sure most of us here used the latest official (260.19.36) when we verified this problem.

[George-carstoiu-g (george-carstoiu-g)]

Considering Comments 5 to 10, I am changing resolution to New.

Can someone with a Nvidia card please perform a regression range?

[Julien Wajsberg (felash)]

I've no problem with the "open source" nv driver on Firefox 4 beta 1. I'll check with the nouveau driver later.

[T-artem (t-artem)]

(In reply to comment #12)
> I've no problem with the "open source" nv driver on Firefox 4 beta 1. I'll
> check with the nouveau driver later.

nouveau driver doesn't have this problem according to people commented on nvnews.net:

ShiningArcanine wrote:
> I tried switching to the Nouveau driver on my laptop and it eliminated the lag issues

[Julien Wajsberg (felash)]

Yes, I can confirm this.

[George-carstoiu-g (george-carstoiu-g)]

Artem, are you still able to observe issue?

[T-artem (t-artem)]

(In reply to comment #15)
> Artem, are you still able to observe issue?

Yes, I'm now running NVIDIA drivers 270.26. Like NVIDIA developers said the problem is that:

"... it appears that Firefox is using an enormous pixmap
that exceeds the GPU's maximum rendering dimensions, causing software
fallbacks."

and since they haven't yet solved it, the issue is still in effect. However it's worth mentioning that neither Opera, nor Google Chrome has this bug.

[T-artem (t-artem)]

Funnily even relatively short web pages cause huge CPU spikes and slowness, like this one: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/19556

[Jacopo Moronato (jmoronat)]

See also this: https://bugs.launchpad.net/firefox/+bug/223238

[T-artem (t-artem)]

BTW, scrolling is *not* necessary - Firefox takes up to 2 seconds just to switch to *any* page on bugs.launchpad.net, like this one: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/734615 - this web page is now only three-four screens long.

[George-carstoiu-g (george-carstoiu-g)]

*** Bug 644275 has been marked as a duplicate of this bug. ***

[Irv-soundforsound (irv-soundforsound)]

same for me. using 260.19.36 with a GeForce 6200.

Xorg cpu usage goes through the roof, even when not scrolling

User Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0

build from mozilla.org.

Not limited to just launchpad, the "My eBay" page for me exhibits the same, to the point of being unusable

[Mike (bild85)]

seconded. It is very frustrating to work in Launchpad because of this. I am a very active surfer and Launchpad is the only site that exhibits this behavior. Maybe the root cause is a bug in Firefox, but someone has the ability to fix this.
Marked bug #748087 a dupe of this one.

[Robert Collins (lifeless)]

I've unmarked it as a duplicate; the underlying fault in firefox still needs rectification.

[Mike (bild85)]

I opened a bug in Launchpad for this same issue:
https://bugs.launchpad.net/firefox/+bug/748087

[Mike (bild85)]

Thanks Robert. I found this same bug in Bugzilla so added a comment linking back to here:
https://bugzilla.mozilla.org/show_bug.cgi?id=629234

[Cas (calumlind)]

@Michael the Launchpad bug, https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/605567 has already been raised and associated with this one.

Also I should make the point that I commented in LP605567 that the other bug reports (https://bugs.launchpad.net/firefox/+bug/223238 & Bug #490563 ) are not the same as this one due to bug age and narrow range of sites affected.

[Ralph Corderoy (ralph-inputplus)]

I disagree this is a duplicate of bug #605567. That is on Firefox asking it to cope better with sprites that are particularly large as some graphics drivers, e.g. proprietary Nvidia cope poorly. This bug is on launchpad suggesting it better pack its sprite image so that is is more dense and more square so as to not tax less programs that have to deal with it. (Launchpad should also sort out the Content-Type header whilst it's at it.) Please cancel the "duplicate" for this bug.

[T-artem (t-artem)]

Can anyone check if 275.19 driver solve this issue?

http://www.nvidia.com/object/linux-display-ia32-275.19-driver.html
http://www.nvidia.com/object/linux-display-amd64-275.19-driver.html

From changelog:

"Fixed poor X driver handling of pixmap out of memory scenarios."

[Cleanrock (cleanrock)]

275.19 did not solve this issue for me.

[Xruptor Darkwater (xruptor)]

This bug still exists. With every update to FireFox this issue hasn't been addressed. It's only getting worse and worse. It seems the 2D painting is not properly functioning. This only occurs with Nvidia drivers. I've had to switch to another browser for the time being because browsing the internet has become unbearable on FireFox. Please this really needs to be looked at. Many people are affected with this problem.

https://bugs.launchpad.net/firefox/+bug/605567

https://answers.launchpad.net/ubuntu/+source/firefox/+question/165246

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/855414

[cicoandcico (cicoandcico)]

I can confirm the problem is still present on Ubuntu 11.10.
Firefox 7, nvidia driver 280.13, geforce quadro nsv140 m.

[Xruptor Darkwater (xruptor)]

I can also confirm this bug still exists in Ubuntu 11.10. Nvidia driver 280.13 Firefox 7

[Greylander (greylander)]

I can confirm that Firefox 8, on Ubuntu 10.04 still has this bug.

The problem is so common for me that I just always expect it -- I do not think it matters at all what web page one is looking at.

I have chrome browser, side by side Firefox, both on this web page (this bug report page). Chrome scrolls smooth as silk and is extremely responsive. Firefox is jittery with much lag.

Example of behavior: I use smooth scroll mouse wheel. Flick the scroll wheel, and maybe it zips up pretty quick halfway, that stops suddenly -- with the wheel still spinning fast. Do same in chrome and it scrolls all the way up (or down).

Generally speaking it is as if scrolling simply stops at random moments for up to 2-3 seconds (though about 1/2 second is probably most common).

[Feedback-launchpad (feedback-launchpad)]

Photon added the following comment to Launchpad bug report 605567:

Confirmed with Firefox 9.0.1, nvidia 290.10, Arch Linux.

--
http://launchpad.net/bugs/605567

[Ralph Corderoy (ralph-inputplus)]

WRT CSS sprite packing, I don't know how Launchpad currently does it, but there are programs like http://glue.readthedocs.org/en/latest/quickstart.html to help.

[Matt Alexander (mattalexxpub)]

Confirmed:

Debian 6.0.3
flashplugin-nonfree i386 1:2.8.2
iceweasel 9.0.1-1~bpo60+1

[Matt Alexander (mattalexxpub)]

> flashplugin-nonfree i386 1:2.8.2

I meant nvidia-glx 195.36.31-6

[David Schneider (dnschneid)]

Confirmed with Firefox 10.0.2, nvidia 295.20, Ubuntu 11.10.

Offending pages include Launchpad bug tracker, due to its 64x22031 sprite sheet
https://bugs.launchpad.net/+icing/rev14914/icon-sprites
and the new Dropbox design, which features a whopping 64x30030 sprite sheet (which performs even worse than the Launchpad one):
https://www2.dropbox.com/static/1331165834/images/sprites/sprites.png

As more and more web applications switch to sprite sheets to reduce page loading latency, new examples are going to become more frequent.

[Lemmiwinks (lemmiwinks)]

Confirmed for Firefox 11.0, Ubuntu 11.10, Nvidia 280.10.

And pre-confirming for Firefox 12.0 to 99.0.

What really drives me mad about this bug is that not only it doesn't get fixed for such a long time, but also I have the impression that firefox becomes a Windows-only browser. When I fire up Firefox on Windows XP, it is an extremely fast browser that does not leave anything to be desired.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r15354 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/15354>.

[T-artem (t-artem)]

Am I the only one for whom this page http://blog.neverendingo.de/?p=125 exhibits the same problems? (Jerky scrolling and 100% CPU usage)

Is it the same problem or I should post a separate bug report?

(Firefox 14 beta10 here, NVIDIA 290.10)

[Ttaubert (ttaubert)]

*** Bug 671862 has been marked as a duplicate of this bug. ***

[Julien Wajsberg (felash)]

I'd say it's different and more related to the fixed background with semi-transparent div layered on top of it.

As a hint, changing the zoom level doesn't help whereas it helps in other testcases.

[Ralph Corderoy (ralph-inputplus)]

I think this is improved but not fixed. This page is pulling in https://bugs.launchpad.net/+icing/rev15694/inline-sprites-1.png that's 20px × 9,805px and I'm using firefox 11.0+build1-0ubuntu0.10.10.2 on Nvidia hardware (Acer Aspire Revo). Whereas originally it would not redraw for a long time it's now usable.

Using Page Up/Down on the keyboard I find the scrollbar thumb responds instantly and the page redraw follows sometime later. The smallest delay is one second or slightly over when I'm roughly in the middle of this bug report. It slows down at the bottom and is very slow at the top of the page and for quite a while moving down through it. I think it all depends on how many references to that tall sprite are in the area to be redrawn.

Can it not become more squarish instead of persisting in being extreme in one dimension, e.g. comment #36.

[Supergernot (supergernot)]

Confirmed for Iceweasel 15 on Debian Wheezy, NVIDIA 304.51. Chromium runs just fine.

[A-eibach (a-eibach)]

Well, this animal here is still running Iceweasel 10.0.4, but I think that doesn't matter.
Nvidia card yes (GeForce FX series). Running nouveau drivers, no proprietary ones.

What Artem said in his initial post, proved WRONG on my machine. I had IW 3.6.13 for quite a long time, and it always worked marvellously, even with "difficult" sites.

However: this has visibly changed once I decided to move over to a new libc and base system.
Since then, I recognize the following:

- Tab switching from $COMPLEX_SITE_1 to $COMPLEX_SITE_2 takes literally ages (up to 3 seconds)
(People claimed to cure this by applying the Ubuntu (!) version of libcairo 1.12.* (which, unline the current (!) non-testing Debian version does without server gradients) but frankly, that rather resembled some voodoo magic. No significant changes with that "tweak" on here, whatsoever.)

- Scrolling with Javascript-heavy sites is a nightmare.
I'll try to describe:

Site scrolling movement always seems to "hang behind" the mouse wheel. So you would press the mouse wheel *gently*, and with a decent delay, the page would scroll down resp. up. Yeah, it's like some satellite communication back in the 1980s :) You'd crack a joke, and 30 seconds later the person on the other end bursts out laughing :) It's very odd.

You would

[lokster (lokiisyourmaster)]

Can confirm this bug too - for example after logging in dropbox.com
Using 64-bit Kubuntu 12.04 based distro, with KDE 4.10.1, proprietary Nvidia 310.14 drivers and Firefox 19.0.2
Actually I'm having this bug since forever - way before it was reported.
I can also confirm that changing zoom level makes the things better.

[lokster (lokiisyourmaster)]

A quick workaround I've just come up with: install the "Default Zoom Level" extension, and set the default zoom to 101%.
This way, the zoom is barely noticeable, and the bug is gone...

[Adam Porter (alphapapa)]

I'm glad to have found this bug report. I've been having this problem for a long time now. I've exclusively used Firefox on Linux for so long that I had gradually become somewhat accustomed to it. I was frustrated with how slow it was, even doing simple things like switching between open tabs, but it's only when I use Firefox on another machine or in Windows that I notice that doing the same things is nearly instantaneous. It also seems much faster using Firefox in Linux on a machine with an AMD GPU. But my old laptop with an NVIDIA 8400M GS is so, so slow with Firefox...I really hope someone can fix this.

[T-artem (t-artem)]

(In reply to Artem S. Tashkinov from comment #35)

http://blog.neverendingo.de/?p=125 is still incredibly sluggish, however launchpad pages now work fast.

Has launchpad been redesigned recently?

[Julien Wajsberg (felash)]

I wonder if we could not turn on tiling on desktop ? Or do this if we detect a nvidia/linux driver ?

[Nical-bugzilla (nical-bugzilla)]

(In reply to Julien Wajsberg [:julienw] (in MozSummit until next monday) from comment #44)
> I wonder if we could not turn on tiling on desktop ? Or do this if we detect
> a nvidia/linux driver ?

Tiling requires OMTC + layers acceleration. We have a lot to do before we get there. I recently tested OMTC+tiling on linux and it is very unstable.

These days there's been a lot of efforts put in turning on OMTC for desktop platforms (mac and soon windows). Electrolysis also requires OMTC. So we'll eventually get there on linux too but it's not a top priority for now. It's a great place for contributions, though. If anyone's interested, I can mentor contributions in this area.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/744808

[Julian Alarcon (julian-alarcon)]

Somebody can confirm if this bug is still Present on Ubuntu 12.04, 13.04 or 13.10 and current Firefox version (24)?

I'm using nVidia card and Firefox 24 on Ubuntu 13.04 and all seems fine. But, do you have another test page? Seems that Launchpad.net already "fixed" the problem.

[Ralph Corderoy (ralph-inputplus)]

Hi Julian, Are you sure you haven't told the browser to scale launchpad
pages slightly? That's the workaround I use. Ctrl-0 would reset that.
https://bugs.launchpad.net/+icing/rev16799/inline-sprites-1.png is still
9,000+ pixels tall, so that hasn't changed.

[[e-mail] (mrmiko)]

Can confirm this bug too - for example at Google images https://www.google.de/imghp
Scrolling is very slow and leaks for seconds.
I am using 64-bit Debian wheezy based distro (crunchbang), with Openbox 3.5, Nvidia GTS-450 with
proprietary Nvidia 325.15 drivers and today updated to iceweasle 24 via wheezy-backports

Other browsers like chromium works like a charm. Same system only with Intel onboard graphics also works properly.

This bug occurs for years.

[P-tim (p-tim)]

I am experiencing the same issue, with an NVIDIA GeForce 7800 GTX on Debian Wheezy. Iceweasel and Firefox both exhibit slow and choppy scrolling with high Xorg CPU usage. I'm using the proprietary NVIDIA driver, version 304.88.

[Jurwolf (jurwolf)]

The same story, awful scrolling with Firefox 26 and 304.117 nVidia (GeForce 6100/nForce 410).
Some known tweaks via about:config + disabled smooth scrolling = minor changes.

No any problems with Chrome.

[A-eibach (a-eibach)]

Can you please elaborate on those tweaks? It will be better than nothing, since telling from current developers' interest, I'm pretty sure this bug won't be fixed until end of 2015 (if at all). Developers usually use cutting-edge hardware---also graphics cards---so they won't care much about problems with "old" cards.

[Jurwolf (jurwolf)]

And again: mentioned FF-tweaks are completely unuseful with PROPRIETARY nVidia driver.

2015???
OK, I will use Chrome/midori or something else based on webkit.

[Fernookie (fernookie)]

Firefox is now v29. Linux Mint 14 - 64 bit here, nVidia GTX 560 Ti, driver version 304.117. Bug is still unresolved, Firefox stutters on every page. Looks like they simply don't care.

[Julien Wajsberg (felash)]

We could reasonably argue that nvidia doesn't care either :)

[U494960 (u494960)]

Solution is here: www.waveguide.se/?article=speed-up-that-sluggish-iceweasel-firefox
Works for me, no lags at now.

----
Manjaro Linux (XFCE, kernel 4.1.3)
Nvidia 304.125
Firefox 39

[U494960 (u494960)]

+ additional useful tweaks: https://wiki.archlinux.org/index.php/Firefox_tweaks

[Sandreas41 (sandreas41)]

Thanks for that tip Jurgen, that restores the snappy speed I expect from my system. (Sempron,Nvidia,Debian,noveau driver)

However a tweak does not really Fix the bug, and to that end, I'd like to know if this sample page is the same problem? (or if I should file a new bug report that affects current Iceweasel/Firefox and Seamonkey-2.33.1)
http://seahorseCorral.org/weatherRadar-tiw-overlay3.html

Without tweaking anything, the refresh rate is about once per 20 seconds. Effectively makes the page useless in Firefox.
and adjusting the page zoom does not change the behavior. Idea: Try using the menu, it may take 2 minutes to navigate to the zoom settings... :P

When the image width and height are 1:1 to the actual size, it works fine:
http://seahorsecorral.org/weatherRadar-tiw-overlay1.html

[U494960 (u494960)]

Stewart, per my experience with all browsers - I recommend you to use QupZilla for work and Chromium for video.

[Ralph Corderoy (ralph-inputplus)]

Why does this bug on launchpad have status `Fix released'?
This page has just served me the same tall image that's been causing
the problem all along. It could clearly be packed to a lot less
pixels in a different arrangement giving an a squarish shape.
Just like so many other websites manage.

20x9919 https://bugs.launchpad.net/+icing/rev18667/inline-sprites-1.png

[Colin Watson (cjwatson)]

Well, it's not quite as it was all along - the packed sprite images were pruned and split into two. But if it's still a problem I can certainly reopen the bug.

[Ralph Corderoy (ralph-inputplus)]

Hi Colin, No, you're right. Its height was 20,553, now down to 9,919,
as I noted in #45 in 2012. My hardware has changed so I'll leave it to
others to say if it's fixed. Thanks for changing status to Triaged.

[Colin Watson (cjwatson)]

I spent some time playing with this today. It is possible to use a
squarer layout for sprites, but there are some significant
complications, which is probably why previous developers didn't do it.

The main problem is that, with our current CSS, background images are
only clipped according to the width and height of the element that
they're attached to. We get away with this for height because elements
aren't usually all that high, so we can just have a generous vertical
margin. But elements are frequently a lot wider than they are high, so
once we try to lay out images horizontally we end up with superfluous
images showing up from further right in the combined sprite image unless
we set enormous horizontal margins, at which point we're back to
combined sprite images that don't fit in GPUs.

The fix for this is probably to use CSS pseudo-elements. Instead of
setting an image as the background for its associated element directly,
we'd create another element using :before with fixed width and height
and set the image as the background for that (and then we could probably
stop bothering with margins within the sprite entirely). This
sacrifices support for versions of IE earlier than 8
(https://caniuse.com/#search=%3Abefore), but that's about 0.03% of
global browser use at this point (https://caniuse.com/usage-table), so
we can probably cope with that.

I have this sort of working locally, but there are a lot of layout bugs
right now, and it'll take some time to get all those ironed out.

[Sledru (sledru)]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

[Artem S. Tashkinov (birdie-github)]

This bug has more or less lost its relevance considering that modern GPUs have at the very least 3gigs of VRAM and new Firefox releases don't support old operating systems where older GPUs might be used.

[Jerabekluk-h (jerabekluk-h)]

Hi, I experience the same on Beyond Linux from Scratch 9.1, with NVIDIA drivers 450.80.02, using X window system on firefox. Same problem appeared when I compiled KDE's browser Falkon. So I have a modern GPU Nvidia GTX 1050, but only 2gigs of VRAM. Does anyone have an idea for some configuration or some kind of hack how to get rid of this problem? Pretty annoying.

[W-jan-k (w-jan-k)]

Open about:config, set gfx.webrender.all to true and restart Firefox to force-enable hardware rendering.
If you encounter problems with it, please report a new bug: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A+WebRender