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

Bug #744808 reported by Ralph Corderoy on 2011-03-29
This bug affects 57 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Mozilla Firefox

Bug Description

Ubuntu 10.10. Viewing a bug, e.g., 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 then fast snappy
speed is restored. This is a PNG although the HTTP server is specifying
a text/plain content-type.

    $ HEAD | grep Content-Type
    Content-Type: text/plain
    $ wget -qO- | 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
    Re: 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.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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.

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

Works fine for me

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

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:

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?

I can confirm this on nvidia.
I am running archlinux, firefox 3.6.13, xorg 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.

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:

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

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

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?

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.

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

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

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

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

(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

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

Yes, I can confirm this.

Artem, are you still able to observe issue?

(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

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.

Funnily even relatively short web pages cause huge CPU spikes and slowness, like this one:

BTW, scrolling is *not* necessary - Firefox takes up to 2 seconds just to switch to *any* page on, like this one: - this web page is now only three-four screens long.

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

Ian Booth (wallyworld) on 2011-04-01
tags: added: performance ui
Changed in launchpad:
importance: Undecided → High
status: New → Triaged

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

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

Mike (bild85) wrote :

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) wrote :

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

I opened a bug in Launchpad for this same issue:

Mike (bild85) wrote :

Thanks Robert. I found this same bug in Bugzilla so added a comment linking back to here:

@Michael the Launchpad bug, 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 ( & Bug #490563 ) are not the same as this one due to bug age and narrow range of sites affected.

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.

summary: - Redrawing of Bug View page very slow in Firefox
+ image sprite is packed very asymmetrically and triggers poor rendering
+ performance in firefox
summary: image sprite is packed very asymmetrically and triggers poor rendering
- performance in firefox
+ performance in firefox3 and missing icons in firefox4

Can anyone check if 275.19 driver solve this issue?

From changelog:

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

275.19 did not solve this issue for me.

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.

Changed in firefox:
importance: Unknown → High
status: Unknown → Confirmed

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

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

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).

Photon added the following comment to Launchpad bug report 605567:

Confirmed with Firefox 9.0.1, nvidia 290.10, Arch Linux.


description: updated
tags: added: easy


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

> flashplugin-nonfree i386 1:2.8.2

I meant nvidia-glx 195.36.31-6

Confirmed with Firefox 10.0.2, nvidia 295.20, Ubuntu 11.10.

Offending pages include Launchpad bug tracker, due to its 64x22031 sprite sheet
and the new Dropbox design, which features a whopping 64x30030 sprite sheet (which performs even worse than the Launchpad one):

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

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

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.

Curtis Hovey (sinzui) on 2012-05-29
description: updated
Curtis Hovey (sinzui) on 2012-05-31
Changed in launchpad:
assignee: nobody → Curtis Hovey (sinzui)
Curtis Hovey (sinzui) on 2012-06-02
Changed in launchpad:
status: Triaged → In Progress
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Curtis Hovey (sinzui) on 2012-06-04
tags: added: qa-ok
removed: qa-needstesting
Ian Booth (wallyworld) on 2012-06-08
Changed in launchpad:
status: Fix Committed → Fix Released

Am I the only one for whom this page 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)

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

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.

Curtis Hovey (sinzui) on 2012-07-12
tags: added: disclosure sharing

I think this is improved but not fixed. This page is pulling in 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.

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

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

Can confirm this bug too - for example after logging in
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.

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...

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.

(In reply to Artem S. Tashkinov from comment #35) is still incredibly sluggish, however launchpad pages now work fast.

Has launchpad been redesigned recently?

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

(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) wrote :

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

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Julian Alarcon (alarconj) wrote :

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 already "fixed" the problem.

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. is still
9,000+ pixels tall, so that hasn't changed.

Can confirm this bug too - for example at Google images
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.

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.

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.

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.

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

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

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.

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

Curtis Hovey (sinzui) on 2017-05-15
Changed in launchpad:
assignee: Curtis Hovey (sinzui) → nobody
Changed in firefox:
status: Confirmed → Unknown

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.


Colin Watson (cjwatson) wrote :

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.

Changed in launchpad:
status: Fix Released → Triaged

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.

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
(, but that's about 0.03% of
global browser use at this point (, 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.

Changed in firefox:
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.