64401 - Extremely slow performance with png background

Status: RESOLVED FIXED

(Core Graveyard :: GFX, defect, P4)

Description

[Mats Palmgren (inactive)]

Extremly slow performance when scrolling and resizing the window at
all pages at http://www.nessus.org

The problem seems to be caused by the background image:
http://www.nessus.org/n.png


PLATFORM and BUILD:
2001-01-04-04 trunk, Windows NT 4 sp6.

Comment 1

[Håkan Waara]

Well heg *it is* the background image. Sounds pretty logic to me; big image
makes scrolling slower.

So this is obviously not a bug in Mozilla, but a problem for the webmaster of
nessus.org. Please bug him about this. Marking INVALID.

Comment 2

[Jure Repinc (JLP)]

I think it shouldn't be marked invalid.
IE5 is usually fast when viewing that page.
Mozilla 2001010420 is not.

Comment 3

[Azrael AOD]

I get this very slow too. And yes it is the background image that's causing it
as far as I can tell.
But IE responds much faster, also in IE the background is fixed and stays so, in
Mozilla it doesn't.
Is fixed background not working the same way in Moz?

Comment 4

[Jure Repinc (JLP)]

I have the problem with non fixed background too.

Comment 5

[Azrael AOD]

Attachment: testcase of one of the pages, with background altered to not be fixed.

Comment 6

[Azrael AOD]

hwaara's gonna kick me maybe.. but if IE can do this faster than Moz, then 
there is a problem. And I think it should be looked at. Re-opening.

Comment 7

[tenthumbs]

n.png is yet another example of a PNG with a fully opaque alpha channel.

File: n.png (42483 bytes)
  chunk IHDR at offset 0x0000c, length 13
    900 x 1000 image, 32-bit RGB+alpha, non-interlaced
  chunk gAMA at offset 0x00025, length 4: 0.45455
  chunk bKGD at offset 0x00035, length 6: red = 255 green = 255 blue = 255
  chunk pHYs at offset 0x00047, length 9: 2834x2834 pixels/meter (72 dpi)
  chunk tIME at offset 0x0005c, length 7: 24 Jul 2000 09:44:17 GMT
  chunk IDAT at offset 0x0006f, length 8192
    zlib:  deflated, 32K window, default compression
  chunk IDAT at offset 0x0207b, length 8192
  chunk IDAT at offset 0x04087, length 8192
  chunk IDAT at offset 0x06093, length 8192
  chunk IDAT at offset 0x0809f, length 8192
  chunk IDAT at offset 0x0a0ab, length 1332
  chunk IEND at offset 0x0a5eb, length 0
No errors detected in n.png (98.8% compression).

so this bug is almost certainly a dup of 64188.

Comment 8

[Keyser Sose]

Definate dupe of bug 64188


*** This bug has been marked as a duplicate of 64188 ***

Comment 9

[tor]

Not a dup - bug 64188 is about tiling small alpha composited images, which
we do very inefficiently.

Comment 10

[Brian 'netdragon' Bober]

Notice 1: .png by itself causes same problem for me.
Notice 2: The .png image isn't appearing for me on Internet Explorer so of 
course Internet Explorer would be faster. You might want to check whether its 
appearing for you. Maybe I don't have a .png library installed.

I compared this page with www.mozilla.org - significant performance difference. 
Comments?

Comment 11

[Brian 'netdragon' Bober]

By the way: tested with Moz.7

Comment 12

[Asa Dotzler [:asa]]

setting bug status to New

Comment 13

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 14

[Tom Everingham]

still happening on 2001041212, adding [imagelib] keyword

Comment 15

[Angela Butler]

Per PDT Triage effort: changing the targeted milestone to "Future".
Please feel free to renominate/address bug if time is available AFTER all
currently targeted 0.9.1 bugs are resolved.
.Angela...

Comment 16

[David Einstein]

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

Comment 17

[Tom Mraz]

I don't see any perf problems on the www.nessus.org.
Linux 2001070208.
Did they do anything with that site? Or is it Windows only problem?
Please retest it with current nightlies.

Comment 18

[Brian Rogers]

This bug needs a better summary.
I suggest "Slow performance compositing image with alpha channel"

Comment 19

[Aleksander Adamowski]

See also http://office.altkom.com.pl/mozilla/browser/slow_bg_png (testcase I did
long tim ago in bug 99153 in case the nessus page gets modified).
It seems that this bug has gone away (Linux trunk build 2002011806).

Comment 20

[Julien Cegarra]

Worksforme. (Build ID: 2002 01 287 08/Win98).

Could we close that one now ?

Comment 21

[Aleksander Adamowski]

Julien: notice that currently this bug has OS set to Windows NT. It cannot be
reproduced on Linux and if you can't reproduce it on Windows 98, it doesn't
necessarily imply it is fixed on Windows NT/2000.
In fact, bug 99153 (which is probably a dupe of this, but that's not sure) can
still be reproduced on Win2K with latest builds.

Comment 22

[Brian 'netdragon' Bober]

I still notice this on Windows XP 2002021803. I compared it to IE, and My
Netscape on Mozilla and it still scrolls a lot slower and there is no change
since Netscape 6.2.1 came out.

Comment 23

[Dimitrios]

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

Comment 24

[Dimitrios]

Adding "with png background" to summary.

Comment 25

[Olivier Cahagne]

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

Comment 26

[Ryan Pertusio]

A large .png image is causing problems with scrolling (and general performance)
on Windows 2000 in the following bug:

bug 124150 - 100% cpu usage when scrolling page with large background image

On testing of THIS bug, using latest nightly (build 20020507) on Windows XP, I
indeed see the problem as described in both of these reports.

Comment 27

[Matt Robinson]

Attachment: Another test with two test-cases (alternate stylesheet)

This test case is also available at http://lazycat.org/alphatest/
The scrolling is incredibly slow, and uses 100% CPU on both methods.
Furthermore, the alternate stylesheet (which uses the same PNG-with-alpha in
all DIV tags) shows markedly different colour in the scrolling DIV with the
main content.  It's still transparent, /barely/, but it looks like it's being
drawn multiple times (the colour is almost exactly three times as dark?)
Should I file that as a separate bug?
For those who don't know, change the style-sheet in the "View" menu's "Use
Style" option.

Comment 28

[Mikko Rantalainen]

Another page that is really sluggish because of this:
http://www.bersvendsen.com/gallery/css/alpha.html
Try using mouse wheel on that one...

I'm not sure if that's because of Mozilla or because of OS. I'm running W2K and
mouse wheeling that page rapidly and then immediatly moving mouse around makes
my mouse all jumpy so it seems the OS is stalling. I've ATI Radeon 7200 with
driver version 6.13.10.6200 in case this is display driver dependant.

Opera and IE seem to be much faster on that page (though, IE is cheating so I
don't care about that one).

Comment 29

[Marius Strumyla]

i found that when scrolling a large (in pixels not in kylobites) png or gif
image, it is very slow with CPU usage at %100. 
same image converted to jpg doesn't show the problem.

i'll attach three images (png, gif, and jpg) taken from 
http://www.i-conductor.com/images/bg.gif 

this doesn't happen on Win98, only on NT

Comment 30

[Marius Strumyla]

Attachment: bg.png (causes slowness)

Comment 31

[Marius Strumyla]

Attachment: bg.gif (causes slowness)

Comment 32

[Marius Strumyla]

Attachment: bg.jpg (ok)

Comment 33

[Marius Strumyla]

cc'ing myself

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can affirm this anoying problem since the 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 version
of Mozilla. It's also still happening within the latest avaible compiled
nightlies from Oct. 2nd. 

Best example is (like comment 28):
http://www.virtuelvis.com/gallery/opacity/old/alpha.html

Following checkin is conspicuous:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=&file=nsImageWin.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=07%2F18%2F2003&maxdate=08%2F17%2F2003&cvsroot=%2Fcvsroot

As addition: On another machine i see it also on all versions of Firebird
greater than 0.6.1.

Comment 35

[TGOS]

Firebird 0.6.1 had good performance on all test cases. Still worse than IE in
some cases (even in cases where IE was *not* cheating!), but acceptable. The
performance of Firebird 0.7 sucks.

I'm currently playing an online (browser based) strategy game (similar to
Civilization). Scrolling on the map (which uses lots of alpha transparent PNGs
covering each other to get field boundaries, units, terrains and buildings onto
a single map field) is lighting fast in IE. In Firebird 0.6.1 it's slower, but
still fast enough to be playable. In Firebird 0.7 and latest nightly builds,
it's so horrible slow that the the game is unplayable.

The reason behind all this is that the native image render acceleration of
Windows has been disabled. Why? Well, there are good reasons: bug 205893 and bug
204374

To avoid that you have to go over there, here's the problem in short:

Every cached image (cached for fast rendering) consumes a GDI handle. This leads
to two problems:

1) On Win9x/ME the number of handles is limited! Windows only reserves 2 MB for
all handles together. I don't know how big such a handler itself is, but 2 MB
means the number of handlers is not infinite (Win 3.1 even had only 64 KB
reserved for handlers). If you run out of handlers, the system GUI can't work
correctly any longer: Dialog boxes can't be displayed any longer or come up
empty. Pictures and windows aren't removed anymore from the screen and paint
over each other. In the worst case, the system can crache. In the past, Mozilla
used only 4 MB of memory to cache images, this limited the number of images
(absolute number depending on the size of images on web pages) and that way the
number of handlers was also limited. But this static memory model has been
replaced by a dynamic one (the more memory your system has, the more Mozilla
will use as cache by default - There is also a bug for this topic, bug 105344)
and now Mozilla may lead to serious render mistakes if acceleration is
activated. E.g.: http://bugzilla.mozilla.org/attachment.cgi?id=126443&action=view

2) Even if you use WinNT/2k/XP/2003 you may still run into another problem.
These four have no limit on the number of GDI handles (the reserved space is
extendable at any time), but for every GDI handle an image space of at least
*one megabyte* is reserved. It can be bigger than one megabyte, but it can't be
smaller. That means if a 34 byte large image (the smallest image possible) gets
a GDI handle, it's cached within a memory block that is one megabyte in size
(over 99% wasted memory!). Of course in Win9x/ME you have the same problem, but
here the number of handles is way too limited, so you will rather run out of
handles than out of memory. But on the other four, visiting a webpage using many
small images (and if the same image is used several times, it will get a handle
several times!) you can force the system to run out of memory (not just out
physical memory, but out of virtual memory, too) and then say goodbye to your
system (as it will hardly react any longer and only if you are lucky, you could
still kill Mozilla to save your system). The problem is that this happens very
fast. While your system may still run perfectly stable with 800 images, it may
crash completely with 1000 images.


To fix both bugs for the 1.4 release, the usage of accelerated images via GDI
handles has been disabled. See:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/gfx/src/windows&command=DIFF_FRAMESET&file=nsImageWin.cpp&rev1=3.121&rev2=3.122&root=/cvsroot


There are a two constructive ideas how this situation might get fixed. See the
following comment:

http://bugzilla.mozilla.org/show_bug.cgi?id=204374#c338

But whether one of both solutions is also practicable and programable is another
question. So right now this bug is a no go, as it depends on having two other
bugs fixed first. If they got fixed, we can enable acceleration again and this
bug will be gone automatically.

Comment 36

[Lewis Jardine]

 I don't think point 2 in comment 35 ("but for every GDI handle an image space
of at least *one megabyte* is reserved. It can be bigger than one megabyte, but
it can't be smaller.") is correct. 

I've seen mozilla running fine, having allocated over 9000 GDI handles. If
comment 35 is correct, this would mean that it had allocated 9000MB of images.
The x86 has a virtual address space of only 4096MB. (Even if, through some
kernel wizardry, the GDI subsystem somehow allocated all this space, it would
still have to go somewhere. I've seen mozilla running with 9000 GDI handles on a
512MB laptop with a 10Gb hard disk. It doesn't have enough memory (physical or
virtual) for NT to be allocating 1MB per handle).

[e-mail], where did you discover point 2? Have I misunderstood it?

Comment 37

[TGOS]

To comment 36:

You are right, I misread bug 205893
It wasn't disabled because the handle uses one MB, but because one MB is the
smallest possible memory cache size and this leads to the problem that a
malicious page can crash your browser by having too many images cashed with GDI
handles. Still this bug is one of the reasons why acceleration is disabled, so
this bug is blocked by that bug, too.

Comment 38

[Patrick Ruckstuhl]

Attachment: Testcase with many layered pngs, was fast in older firebirds

Comment 39

[chris hofmann]

sounds like several tuning options and side affects would be needed to make this
work right in all cases.  pav/mats, are you looking at this?  any ideas?

we would need a patch and a good deal of testing on the trunk to have enough
confidence to take any fix for this on the aviary branch.   renominate if we get
closer to having those things.

Comment 40

[Joël Kuiper]

I experiance extreme slowness when using tranparant PNG's as background in

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026
Firefox/1.0RC1

I specially experience this in my recently built website which has the following
code: 

#text[id] {
	background: url("images/background.png");
}
#text {
	width: 49%;
	height: 95%;
	border: 1px solid #C1C1C1;
/* IE transparency hack */
	filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true,
sizingMethod=scale src='images/background.png')
}

I do not detect any slowness when using IE or Opera

Comment 41

[Brian 'netdragon' Bober]

Can you provide a testcase for that example?

Comment 42

[Joël Kuiper]

(In reply to comment #41)
> Can you provide a testcase for that example?

Nah I just figured that it isn't the filter propety that causes slowness. 
It's just the PNG background. I now have a site that uses 4(that is not a very
large number) PNG's as background and already the site slower than others. 

Comment 43

[TGOS]

Here another page:

http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_1.html

This page scrolls lightning fast (okay, maybe just average speed, but fast
enough) in every browser, as long it's not Firebird or any other Gecko based
beast. Verified in Windows XP and MacOS X (setting hardware/OS to all).

There used to be a time where PNG images were no problem. Somewhere around 0.7
or so the problem started. And it goes on and on and nobody can really say where
it comes from.

Comment 44

[Joël Kuiper]

Hmm that's odd The testcase is notably faster after I installed the new nividia
drivers for my videocard. But it if it's a problem with my drivers I wonder why
was IE and Opera not affected by this?
New nvidia drivers are 66.93 on my Geforce MX 440.
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217
Firefox/1.0+)

Comment 45

[Brian 'netdragon' Bober]

Perhaps the issue is not the drivers alone, but the combination of Firefox and
the older drivers. Perhaps the newer drivers are optimized better for some kinds
of primitive operations.

What were the old Nvidia drivers? The changelist (if one exists) on drivers
leading up from that might hold some clues.

Comment 46

[TGOS]

I always have the latest drivers installed and it's always slow.

Also, if it is a driver problem, why is it no problem in: IE, Opera, Safari,
Konqueror?

And why was it no problem in Firefox 0.7?

Comment 47

[Brian 'netdragon' Bober]

Will Cairo solve this issue?

spamcop: This is definately a Firefox issue. As I said, they might handle the
graphics differently, and the way Firefox does it might not be done in a way
that is best optimized for the cards. For some reason, the new drivers disguise
the issue for this individual, perhaps in the way they handle memory (I saw your
post about the GDI+ handles). The issue is with Firefox, but if we could find
out what the drivers changed that suddenly caused the issue to disappear, it
might provide a shortcut to solving the problem.

Comment 48

[Joël Kuiper]

I was unable to find any record of my previous drivers on my PC. 
My current driver can be found here http://www.nvidia.com/object/winxp_2k_66.93 .
Perhaps the releasenotes (
http://download.nvidia.com/Windows/66.93/66.93_ForceWare_Release_65_Graphics_Drivers_Release_Notes.pdf
)  Might be of help

Comment 49

[Jasper Lieber]

(In reply to comment #38)
> Created an attachment (id=157810) [edit]
> Testcase with many layered pngs, was fast in older firebirds
> 

this test case render's very poorly on my machine.  i'll attach what the output
looks like when i try to scroll.  so:  confirmed!  there's a problem!

(happily, IE and Avant do much worse jobs of rending the testcase - neither were
even able to show trees - mostly blank diamonds)

by the way - check out bug 201198 and bug 284986...

Comment 50

[TGOS]

@Jon Barber (Comment #49) and the rest: The testcase attachment (id=157810) is
only created for Firefox. That it doesn't work with IE is correct. It is from an
online game, where you can choose between Firefox and IE. The IE version of the
webpage does not rendern on Firefox and the other way round. So I just used the
case because here I saw the problem first.

For a decent test case, please use that link:

http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_1.html

It should show decent performance in IE, Opera, Safari and other browsers. The
scrolling performance is only poor in Mozilla based browsers including Firefox
and Mozilla itself.

Comment 51

[Jasper Lieber]

(In reply to comment #50)
> @Jon Barber (Comment #49) and the rest: The testcase attachment (id=157810)
[edit] is
> only created for Firefox. That it doesn't work with IE is correct. It is from an
> online game, where you can choose between Firefox and IE. The IE version of the
> webpage does not rendern on Firefox and the other way round. So I just used the
> case because here I saw the problem first.
> 
> For a decent test case, please use that link:
> 
> http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_1.html
> 
> It should show decent performance in IE, Opera, Safari and other browsers. The
> scrolling performance is only poor in Mozilla based browsers including Firefox
> and Mozilla itself.


Okay, I understand you.  And I can _confirm_ that IhateMS_1.html does scroll
more slowly in my mozilla than in my IE.  Cheers....

Comment 52

[Zach Smith]

Attachment: Testcase with background including transparancy

The laging is the most severe, I have found, when the background image includes
transparancy.  Changed background image to gif with transparancy.  Also, for
some reason, there is no lag at all, at least until I restart or something,
though I haven't found anything different about those cases.

Comment 53

[ArronM (:paper)]

Zach, are you using a nightly build?  What's your video card and OS?

Comment 54

[Zach Smith]

(In reply to comment #53)
> Zach, are you using a nightly build?  What's your video card and OS?

I'm using Firefox 1.0.1 on Windows XP SP2, and my video card is an NVIDIA
GeForce FX 5200.

Comment 55

[ArronM (:paper)]

Zach, could you try a nightly build and see if you still have the same problems?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 56

[Zach Smith]

(In reply to comment #55)
> Zach, could you try a nightly build and see if you still have the same problems?
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Problem fixed!  Thanks!  I'll remember that, for some reason, nightly builds
scared me.  Not totally out of the question for the reason that a beta MMORPG
crashed my computer one time, but then again, that was Windows ME.

Comment 57

[TGOS]

Call me nuts, but using

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050320
Firefox/1.0+

It really seems fixed. I have not changed anything on my system and at least
under Windows, the performance is better than ever before (as far as I can
remember). Okay, maybe still not *perfect* (what is?), but good enough to view
pages with decent speed that used to be slow as a snail.

Unfortunately my ultimative test case, the online game, is offline at the moment
(they just put up new servers and change the name of the game). But the "Why I
hate MS page" has never been that fast in Firefox. I hope this performance is
stable (as the scrolling in the game was also sometimes faster, but got slower
the longer I had the game open). I have to test this nightly on my Mac tomorrow :-)

But in case it really has been fixed, can someone please give me a pointer
*where* it got fixed? I see no attached fix to this bug, so could someone point
out source code changes I could review, as I'd really like to know *how* this
bug has been fixed.

Comment 58

[Ryan VanderMeulen [:RyanVM]]

This isn't remotely fixed.  I can easily see the issue still.  An easy way to
see it is to have a TV tuner or movie playing next to the firefox window. Notice
what happens to the framerate when you scroll on an offending site.  Not pretty.

I use an AMD Barton @ 2.26 w/ 1GB RAM and a Geforce 6800Ultra on my test system.

Comment 59

[TGOS]

Yes, you are right, playing a video still causes slowness, but I see the same
effect in IE on my machine (Athlon 1 GHz, 768 MB RAM, GeForce 2), although the
effect differs: In Firefox the animation is still smooth (have smooth scrolling
enabled), just a lot slower. In IE the scrolling is not smooth at all anymore
(very tottery), therefor not that much slower.

The bug was about Firefox being much slower on some pages compared to IE or
Opera or Safari. This effect has been fixed, so the bug has been fixed, at least
on my machine.

The difference to IE probably comes from the scrolling alorithm used. IE prefers
to skip most frames, avoiding too much speed down, therefor all smoothness is
gone. Firefox seems to prefer keeping the smoothness, therefor it gets slow
(maybe because CPU is too busy or because graphics card is too busy, causing a
slowness in page redraw, whatever).

The problem I saw before was Firefox being slow, even if no other process at all
was running on the machine and this seems now to be gone with the latest nightly
build.

Comment 60

[ArronM (:paper)]

(In reply to comment #58)
> This isn't remotely fixed.  I can easily see the issue still.  An easy way to
> see it is to have a TV tuner or movie playing next to the firefox window. Notice
> what happens to the framerate when you scroll on an offending site.  Not pretty.
> 
> I use an AMD Barton @ 2.26 w/ 1GB RAM and a Geforce 6800Ultra on my test system.

Do you have smooth scrolling turned on, by chance?  (about:config,
general.smoothScroll)

I tried IHateMS on IE, and found it to stall video even more than Mozilla did. 
Mozilla w/smoothscrolling stalled the video a little bit, and Mozilla w/no
smooth scrolling didn't stall at all.  My test was done with the IHateMS and a
video playing, and I'd scroll the window with the down arrow key (then the up
arrow key, repeat)

spamcop, it's possible that Bug 284716 was the cause of the speed up.

Comment 61

[TGOS]

Okay, just tested on MacOS X, there the slowness hasn't been fixed.

If the Windows speed up came from bug Bug 284716 being fixed, this would explain
why the Mac version is still slow (as it does not relate to the Mac version).

Should we open a new bug for MacOS X slowness, make this one Windows only and
declare it as fixed if we get some more worksforme?

Comment 62

[TGOS]

Okay, with the latest nightly 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050327
Firefox/1.0+

scrolling got slower again and I get bad artefacts under my mouse cursor during
scrolling operations.

Here is a test page that scrolls awful slow and the background is not PNG, it's
JPG. I think the problem is simply with every background, if it's fixed and does
not scroll with the rest of the page:

http://www.pc-maeuse.de/pi-1418104315.htm?categoryId=20

See, awful slow. Try in IE, speedy as hell.

Comment 63

[Robin Monks]

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

Comment 64

[u88484]

I believe this bug is gone now. I tried all of the testcases with Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050415 Firefox/1.0+ and
all scroll fine, not slow at all. I think this was resolved with some fixes a
couple days ago relating to something with fixed backgrounds.

Comment 65

[TGOS]

My one is newer

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050418
Firefox/1.0+

and still slow (compared to Oprea and IE it really sucks).

Comment 66

[atzaus]

Working For Me
I have tried all the test cases and see no problems. i even tried the ones
posted separately in the thread. Using Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b2) Gecko/20050422 Firefox/1.0+. I think this bug should be closed now

Comment 67

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No, it's still there with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050423

No smooth scrolling on http://virtuelvis.com/gallery/opacity/old/alpha.html.
Anyone else who doesn't use win32 can reproduce it? 

Comment 68

[Matej Barac]

(In reply to comment #67)
> No, it's still there with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
> Gecko/20050423
> 
> No smooth scrolling on http://virtuelvis.com/gallery/opacity/old/alpha.html.
> Anyone else who doesn't use win32 can reproduce it? 

I can confirm all examples listed here on Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3.

Comment 69

[atzaus]

(In reply to comment #68)
> (In reply to comment #67)
> > No, it's still there with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
> > Gecko/20050423
> > 
> > No smooth scrolling on http://virtuelvis.com/gallery/opacity/old/alpha.html.
> > Anyone else who doesn't use win32 can reproduce it? 
> 
> I can confirm all examples listed here on Mozilla/5.0 (Windows; U; Windows NT
> 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3.

You are using a stock 1.03 build I am talking about the nightlys.
http://virtuelvis.com/gallery/opacity/old/alpha.html seems to be working OK with
 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050421
Firefox/1.0+ 

Henrik I'll check on a Linux box tomorrow but even in that case this should be
labelled Linux only.

Comment 70

[Ria Klaassen (not reading all bugmail)]

I tried the last two example-links with Smoothwheel installed:
On a WinXP system with an ADM Athlon XP 2000+ the scrolling is acceptable. It
scrolls not as smooth as the average site but I won't avoid the site or take the
CSS away.
On a WinXP system with an AMD Duron 900 MHz the scrolling is horrible! Even my
cursor jumps when I move it over the page and the scrolling jumps with delays of
more than 2 or 3 seconds while the ventilator is making a lot of noise.

Comment 71

[Ria Klaassen (not reading all bugmail)]

I think this bug can be closed when all the slower processors are in the
Computer's Heaven (or earlier) ;)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050501
Firefox/1.0+

Comment 72

[Pardal Freudenthal (:ShareBird)]

All the test cases here work fine for me. But this site is weird:

http://weblogs.mozillazine.org/djst/archives/005650.html

Comment 73

[TGOS]

Actually all our test cases are really fast with the nightly I have installed now:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050504
Firefox/1.0+

If it just wouldn't crash so often and if my extensions would still work...
anyway, that's another issue. Regarding speed with fixed background, all issues
seem fixed; at least there is no visible speed difference between Firefox and
IE6 anymore on my old 1 GHz machine.

On comment #72:

I can confirm that this link is slow.

http://weblogs.mozillazine.org/djst/archives/005650.html

But first, I don't know if it is fast in other browsers. While it is fast in IE,
IE does not render it correctly at all (and I know why!) and I also know why
Firefox has problems with it:

The background image (the bird house) shines through the wide comment array on
the page when scrolling. This is done using a simple trick:

background:transparent url(images/blogback.png);

I took a look at the blogback.png and it is a PNG with alpha transparency. That
is why IE fails to render the page correctly -> IE6 does not support alpha
transparent PNGs.

And this is also causing the slowness. Firefox has to compose the background of
the text div block after each scrolling operation by merging the transparent PNG
with background, to get the milky background image. IOW the background image is
calculated for every line scrolled and there is no way to cache that or speed it up.

This is thus a different bug than the current one and if you think it should be
optimized, please file a new bug; cause this bug is closed to being declared fixed.

Comment 74

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #73)
Thank you for analysis and explanations about this site. Sorry if it came
"spamly", I didn't realize the real reasons for the slow scroll on this page and
I thought it could be helpfull to report it... I agree this bug can be closed!

Comment 75

[José Jeria]

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

Comment 76

[Joël Kuiper]

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

Comment 77

[Peter Hewitt]

Comment #73 says IE doesn't render it properly. IE7 now does render
http://weblogs.mozillazine.org/djst/archives/005650.html properly and it is also
slow and "jiggles" just like Mozilla does.

http://ez.no/products/add_ons/ez_publish_online_editor is another site that
scrolls slowly for reference

Comment 78

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #77)
> http://weblogs.mozillazine.org/djst/archives/005650.html
> http://ez.no/products/add_ons/ez_publish_online_editor

Both pages are scrolling fine for me with Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.9a1) Gecko/20050924 Firefox/1.6a1 and the offical 1.0.7 build under
Debian. Are other Linux boxes affected or could it be a win32 only issue?

Comment 79

[Francois Ingelrest]

(In reply to comment #78)
> (In reply to comment #77)
> > http://weblogs.mozillazine.org/djst/archives/005650.html
> > http://ez.no/products/add_ons/ez_publish_online_editor
> 
> Both pages are scrolling fine for me with Mozilla/5.0 (X11; U; Linux i686;
> en-US; rv:1.9a1) Gecko/20050924 Firefox/1.6a1 and the offical 1.0.7 build under
> Debian. Are other Linux boxes affected or could it be a win32 only issue?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

It's not fine at all for me (Ubuntu)

Comment 80

[Benjamin Lebsanft]

I experience the same using and all other earlier version

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20051123 Ubuntu/1.4.99+1.5rc3.dfsg-1ubuntu3 Firefox/1.5

Comment 81

[Stuart Parmenter]

This should get fixed once we move to cairo and do some performance work so that we get hardware accelerated compositing.

Comment 82

[Michael Adams]

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.2) Gecko/20060310 Firefox/1.5.0.2

Bug does not seem to exist or be noticeable on CPU performance or having other tabs open.

Comment 83

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Wouldn't block for this, or even really want major churn here on the branch.

Comment 84

[(mostly gone) XtC4UaLL [:xtc4uall]]

this is WFM using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070623 ID:2007062304

since Cairo has now landed i cannot see differences in CPU utilization and scrolling speed between Trunk, Opera 9.2, MSIE 7 testing with all given testcases

-> WORKSFORME ?

Comment 85

[Mats Ahlgren]

I can confirm that this bug exists on Firefox on Linux, testing using the latest Firefox v2.0 from the SuSE (10.2) and Debian (larry) repositories. If one frequents websites which use background pngs (e.g. a 1kb png that's very large), this bug effectively prevents you from using those websites. The lagginess makes the browsing experience -- I regret to say -- completely unusable for those sites.

This was tested using a 2GHz Dothan processor (still a comparatively fast processor), which unreasonably goes to 100% CPU utilization even when idle and the webpage is just sitting there doing nothing. The problem goes away if one switches tabs to another webpage.

I recommend changing the target milestone or upgrading the priority.

This problem did not exist in the Windows version of Firefox.

This problem did not exist on my Linux desktop with a 2.6GHz 4-core processor, though performance was still abit laggy.

Comment 86

[Mats Ahlgren]

addendum (sorry for the spam):

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061023 SUSE/2.0-30 Firefox/2.0

I'd also like to note that background pngs are very common nowadays, especially for the express purpose of semitransparency effects.

Comment 87

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Testcase from given URL doesn't exist anymore. Updating to an URL which still shows this problem on a MacBook (2GHz) and the latest 2.0.0.5pre nightly build.

Comment 88

[Jesse Ruderman]

WFM on Mac trunk.

For the URL in the URL field, I'd guess any slowness is due to the background being fixed rather than it being a PNG.  That would be bug 90198.

Comment 89

[Alfred Kayser]

As both Mac and Windows report this WFM, now the focus needs to be on Linux (and other Xserver based env's) to further test this (on the latest FF 3.0 build?)

Comment 90

[The Anarcat]

I just downloaded the latest firefox (3.0), I'm on Debian GNU/Linux "testing" (lenny) and I'm having no issue displaying or scrolling the URL reported.

I *am* having problems with Iceweasel (which is based on Firefox 2.x), so I guess this would mean the issue is fixed in the 3.x series.

Comment 91

[Andrei Eftimie]

It seems that this bug has re-appeared in Firefox 3.
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0)

(or some sort of version of the bug. its not really related to scrolling, but all Firefox performance is slowed down greatly).

Here is a test case:
http://designpunct.ro/firefox3/png_test_case.html
(i don't know if it is better to give an URL or submit a archived test case)

Try hovering the Menu items (a submenu should appear. suckerfish style).

Now disable the images (via Web Developer Toolbar, Images > Disable Images > All Images or Images > Replace Images with Alt Attribute) second method seems to work better as the first one isnt' reliable sometimes.

Performance is great now. (work ok with images enabled in Firefox 2, or any other browser)

I have nailed down the problem to 1 png:
http://designpunct.ro/firefox3/png_test_case_files/i/background.png
8,894 bytes and 1012x3334 px dimensions

If i take out this png from the css all works well.
http://designpunct.ro/firefox3/png_test_case_files/admin.css
line 13
#wrapOuter, .tr, .bl, .br { background: url(i/background.png) no-repeat left bottom; display: inline-block; }

1. Its not a transparent png
2. File-size is small (~8kb)
3. Dimensions are somewhat big (~1012x3334)
4. it is used on 4 elements in the page (with some overlapping)
5. It is optimized via http://psydk.org/PngOptimizer.php (it could be related as this program also strips the png of its internal headers regarding color "workspace" - don't really remember the actual name of the property)

Comment 92

[Alfred Kayser]

Notes regarding the previous comment:
1. The image is very large (1012*3334). Even if the compressed png is small, internally it is expanded to the full 1012*3334*4bytes (4bytes/pixel) = 13.5MB.
2. The image is drawn four times on top of each to achieve the border effect.

So, a better way would be to have one image for the shading effect on the left&right side, and use a fixed border color for top/bottom. The image for left&right can be 1 pixel wide (and probably only about 100 pixels high).

   <div style="background-image:background.png;padding:0 6px 6px 0">
     <div style="border-top:6px solid darkblue;border-bottom:6px solid lightblue">
        content
     </div>
   </div>

Comment 93

[Andrei Eftimie]

Point taken Alfred, there may be slimmer ways to achieve the same thing.
(until now i haven't taken into consideration UA-optimisations. only server and bandwith-wise. and thus i am (was) under the impression that i would gain some bytes using this technique. However, this is not the point of the discussion.

The real problem is that Firefox 3 chokes where Firefox 2 (and IE6+7, Opera, Safari) have no problems. 

Comment 94

[RNicoletto]

Overview of testcases for this bug.

http://www.virtuelvis.com/gallery/opacity/old/alpha.html ==> WFM
http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_1.html ==> Error 404 (not more avaiable)
http://www.pc-maeuse.de/pi-1418104315.htm?categoryId=20 ==> Error 404 (not more avaiable)
http://weblogs.mozillazine.org/djst/archives/005650.html WFM
http://ez.no/archive/ez_no_archive_2006/products/add_ons/ez_publish_online_editor ==> Error 404 (not more avaiable)
http://designpunct.ro/firefox3/png_test_case.html ==> Error 404 (not more avaiable)

Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre

Comment 95

[José Jeria]

Based on comment 94 -> WFM

Please file new bugs with specific URL:s if you still see this.

Comment 96

[Alfred Kayser]

Marking as fixed by: Bug 564991 - Retain layers and layer contents
(the two remaining test cases are extremely fast now!)

Comment 97

[PJ Digital Marketing]

I just downloaded the latest firefox (3.0), I'm having no issue displaying or scrolling the URL reported.

PJ
http://pjdigitalmarketing.com