241642 - Bad performance with fixed elements and images with transparency

Status: RESOLVED DUPLICATE of bug 284716

(Core Graveyard :: GFX: Win32, defect)

Description

[Jochen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040407 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040407 Firefox/0.8.0+

Goto http://www.krickelkrackel.de

Real bad scrolling. 
Switching from another tab to a tab containing this site is slow.

I can also reproduce this with http://www.krickelkrackel.de/transp_img.htm
(resize height of browser to have something to scroll)

No problems with an image without transparency. No difference 
between PNG and GIF.
To make things better: either make the fixed element not fixed or do not
use an image with transparency. 
I makes no big difference if the there is a fixed element or a
fixed background.

Same problem under Firefox (20040423) and Seamonkey (1.7RC1)

Firefox 20040311 is ok.  (firefox-i686-pc-cygwin.zip)
Firefox 20040315 is bad. (firefox-i586-pc-msvc.zip)

There were no "normal" builds those days...
I have no builds from 0312/0313/0314 so I can't say exactly
when this problem occured.

This NOT only a scrolling problem.

No problem under RedHat 9.0/Gnome2.

Reproducible: Always
Steps to Reproduce:
1. open http://www.krickelkrackel.de/start.htm with a build after 20040311 (or so)
2. scroll page or change to the tab containing the site or make window visible
3. 

Actual Results:  
bad performance

Expected Results:  
performance like the builds before 20040312

Notebook Toshiba Tecra S1. Pentium M1300 with 512MB Ram. 
Mobility Radeon 9000.

My Desktop Athlon XP2600 isn't performing much better.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So do we actually have anyone around doing Windows gfx?

Comment 2

[tor]

Given the timeframe, the regression is probably due to the checkin for
bug 205893.

Comment 3

[Stefan Ring]

tor, you are right.

Interestingly, it is not slow on the Matrox card at work, but it's damn slow on
my GeForce 5200 at home.

Comment 4

[Jochen]

Reducing "hardware acceleration" in WinXP/Win2k by one step
makes things much better.

Comment 5

[Stefan Ring]

Actually I'm not so sure anymore. When I first tried to go back to the original
code, I could swear it was a lot faster. Not so anymore.

Maybe the whole concept of drawing Alpha images has to be rethought.

Comment 6

[Thomas Rutter]

Testcase:
This is a good example of the problem.

http://www.brainstormsandraves.com/articles/semantics/structure/

It is my opinion that this is a very high priority, since this is one of the
main reasons that Firefox *feels* a lot slower than its competitors. 
Particularly for somebody who uses autoscroll (the autoscroll icon works just
like a fixed, partially transparent image as it becomes part of the DOM).

Try autoscrolling (middle clicking and moving the mouse) on this testcase to see
what I mean.

Comment 7

[Stefan Ring]

Started experimenting with this again today...

My findings of this morning: My patch in #205893 indeed makes a difference. It
his, however, not necessarily a difference to the worse. It depends on the
available video ram. Before the patch, it would be very fast with an almost
empty video ram and become really slow as the ram is filled up. After the patch,
this process is actually reversed! - by having other running applications fill
up the video ram, speed goes up drastically.

This is a GeForce FX 5200, Detonator 44.03, W2K. Maybe some other people could
experiment with other hardware/drivers because my findings are not a useful
basis for a resolution of this matter.

Comment 8

[Jochen]

Checkin for bug 284716 fixed the problems.

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