216430 - scrolling slow due to huge background image (regression)

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Jesse Ruderman]

Scrolling using the scrollbar at http://www.dynamism.com/index.shtml is...

fast in firebird 0.6.1
fast in firebird 0729
fast in firebird 0807 \
                      | regression happened in here
slow in firebird 0809 / 
slow in firebird 0816

Test testcase shows that the problem is the huge background image.

Originally reported by Kitsunebi at
http://forums.mozillazine.org/viewtopic.php?p=156256#156256.

Comment 1

[Jesse Ruderman]

Attachment: testcase

Comment 2

[Jason Bassford]

Just to confirm that this is not Firebird specific, scrolling is also slow with
Mozilla 8/15-15 under XP.

Comment 3

[Jesse Ruderman]

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

Comment 4

[Rob Farnell]

This is a good example: http://www.design4online.com/blog/index.asp

Mook mentioned a quick fix:
Enter this in the address bar after going there, and press enter. Scrolling
works fine again. 
 <a href="http://forums.mozillazine.org/viewtopic.php?t=22591">here</a> that
putting the code below completely heals the problem.
javascript:alert(document.body.background="");void(0); 

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this Windows only? Did Linux regress at the same time or not?

Comment 6

[Andrei Leo]

Sorry for spam, but isn't this bug a duplicate of 124150?

Comment 7

[Gert Lutter]

To cause this bug, image height must be >= 1582 or image width must be >= 1601.
Any image with smaller dimensions does not cause this effect.

I’d say the severity of this bug should be increased – it makes Mozilla almost
unusable on Celeron 1100 MHz running win2k and on AMD XP 2000+ it’s very noticeable.

Also, not only is scrolling slow but also selecting text is very slow (lags) and
hovering over links that have hover attribute set via CSS is also very slow.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Gert, is it the image *area* that matters, or is it just if the width > 1601 no
matter what the area is?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Also, CCing tor since this is most likely a GFX/image issue

Comment 10

[tor]

This is due to the stopgap checkin for bug 205893, which turned off optimization
of images on the win32 platform.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

alright then, I'll assign it to you and you can figure out what to do with it :-)

Comment 12

[tor]

Reassigning to jdunn, who did the temporary patch.

Comment 13

[David Tenser [:djst]]

This bug seems to dramatically affect the performance of sites like
http://quadrone.org and even my own blog (http://weblogs.mozillazine.org/djst/).

Gert, none of those sites use images with the dimensions you mentioned. The
dimensions for http://weblogs.mozillazine.org/djst/images/back2.png is 700x1000,
yet the performance is much worse now compared to e.g. Firebird 0.6.

Blocking 1.5?

Comment 14

[Gert Lutter]

Forget I said anything about image dimensions – came back from weekend, tried
again and now the critical dimensions seem to have changed! Small images still
don’t cause slowdown but now image 1500x1500 will… I didn’t try to pin down the
exact values. 700x1000 pixel image still doesn’t cause slowdown for me though.

I tested it by making simple html page and then just changed background image
pixel dimensions and kept reloading.

Comment 15

[chris hofmann]

darin, can you help on this one?  not sure if jdunn is back in action...

Comment 16

[Darin Fisher]

chofmann, sure i'll take a look once i get a win32 build env setup.  btw, this
doesn't seem to be performing badly under linux [firebird-trunk-2003-09-07].

Comment 17

[David Tenser [:djst]]

Gert, my blog uses "background-attachment: fixed". Maybe that's the reason for
the huge slowdown? If so, is there another bug filed for that?

Fwiw though, the performance in recent nightlies is much slower than in Firebird
0.6, so something has definitely happened since then.

Comment 18

[Jim Dunn]

The good thing is that we now know at least one case where using GDI's
is helpful.

Some initial thoughts (and just thoughts...)
-create GDI's for images larger than SOME_SPECIFIC_SIZE,
 otherwise use the current scheme
-use GDI's for backgrounds (and maybe any image that we do
 compositing on (i.e. I wonder if alpha blended images also
 cause a slowdown).  This way, nsImageWin doesn't have to be
 smart but the layout engine is the one that calls nsImageWin::Optimize

I need to run some tests (with & without the fix for bug 205893)
to see the problem for myself.

Darin, thoughts?

And yeah btw, the original patch causing the regression was only on
windows.  The original problem, is still an issue on Linux (since
we never fixed it there.

Comment 19

[Darin Fisher]

as a quick fix, i think we should just make "someone" (either nsImageWin or
imagelib) enable GDI for large images.  then we can go back and do something fancy.

Comment 20

[Darin Fisher]

Attachment: v1 patch

ok, this simplistic patch makes it so that we _will_ optimize images larger
than 128k (that's 128Kb at 24 bpp).  worst case, i think the number of GDI
objects will remain reasonable.  consider 32Mb of GDI objects in the memory
cache... worse case is 256 HBITMAPS (256 * 128Kb = 32Mb).  i think that should
be reasonable.	now, if someone has 1Gb+ of RAM, we might start getting into
trouble.  perhaps, we should also limit the browser's memory cache to some hard
fixed limit, instead of letting it grow unbounded in size (albeit at a
logarithmic rate) as the amount of system memory increases.

Comment 21

[Darin Fisher]

-> me

Comment 22

[Jim Dunn]

Comment on attachment 131109 [details] [diff] [review]
v1 patch

I am going to ok this, but note I have no review authority.

Comment 23

[Darin Fisher]

simon and pav may have opinions on this...

Comment 24

[Stuart Parmenter]

Comment on attachment 131109 [details] [diff] [review]
v1 patch

Well, this is certainly better than the previous patch that should never have
gone in to the tree...	The Win95/98 checks are important and something I had
in my original windows image code.. perhaps they didn't get ported back when I
reverted to the nsImageWin code.  r=pavlov

Comment 25

[Darin Fisher]

Comment on attachment 131109 [details] [diff] [review]
v1 patch

requesting drivers approval for 1.5 final.  i don't think we should ship 1.5
without this patch.

Comment 26

[chris hofmann]

Comment on attachment 131109 [details] [diff] [review]
v1 patch

a=chofmann for 1.5...  lets spin off another bug for redesign work...

Comment 27

[Darin Fisher]

fixed-on-trunk

Comment 28

[Darin Fisher]

ok, see bug 218861 for redesign work.

Comment 29

[Oleg Sidletskiy]

scrolling is definitely a lot faster in testcase.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030910
Firebird/0.6.1+

Comment 30

[Michael Lefevre]

I'm not sure what the status is of 1.4.1, but this is a serious regression in
1.4.1 from 1.4.  I've seen it come up twice in the newsgroups/forums from people
testing the RC build.

Comment 31

[Jon Henry]

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

Comment 32

[dominik.tappe]

answer to comment 20 from Darin Fisher:
the 1Gb+ of RAM case isn't a problem, because Win9X doesn't support that much RAM.

I also want to say that I was using (self compiled) Mozilla builds with the
previous patch for two months, and I cannot reproduce the problem reported in
this bug - all the test cases work fine for me (on 98 SE) with my old build and
with new 1.4.1rc Mozilla. This bug has probably to to with the model of the
graphics card used (i have a Nvidia card).

Comment 33

[Lewis Jardine]

1GB of RAM is an issue on 9x, as it does support that much ram, but there is a
bug in the VCACHE driver which causes it to take up address space equivalent to
the whole physical memory. If left to its own devices, it takes up a whole GB of
kernel address space, leaving none for the rest of the OS. 

If VCACHE is manually set to a sensible size in SYSTEM.INI, 9x can handle 1GB of
RAM. See knowledge base article Q253912 for more details.

Comment 34

[Robert Accettura [:raccettura]]

Is this page effected by the same bug:
http://www.simplygirly.net/

or is it a different bug?

Feels very slow in 1.5

Comment 35

[Jesse Ruderman]

Robert: no, that's bug 90198.  This bug was fixed.

Comment 36

[Robert Accettura [:raccettura]]

Jesse:  Thanks.  Wasn't sure if it was something related to this or not.