Jesse Ruderman Reporter
	Description • 21 years ago

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.

	Jason Bassford
	Comment 2 • 21 years ago

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

	Jesse Ruderman Reporter
	Comment 3 • 21 years ago

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

	Rob Farnell
	Comment 4 • 21 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 5 • 21 years ago

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

	Andrei Leo
	Comment 6 • 21 years ago

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

	Gert Lutter
	Comment 7 • 21 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 8 • 21 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 9 • 21 years ago

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

	tor
	Comment 10 • 21 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 11 • 21 years ago

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

	tor
	Comment 12 • 21 years ago

Reassigning to jdunn, who did the temporary patch.

	David Tenser [:djst]
	Comment 13 • 21 years ago

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?

	Gert Lutter
	Comment 14 • 21 years ago

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.

	chris hofmann
	Comment 15 • 21 years ago

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

	Darin Fisher Assignee
	Comment 16 • 21 years ago

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

	David Tenser [:djst]
	Comment 17 • 21 years ago

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.

	Jim Dunn
	Comment 18 • 21 years ago

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.

	Darin Fisher Assignee
	Comment 19 • 21 years ago

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.

	Darin Fisher Assignee
	Comment 20 • 21 years ago

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.

	Darin Fisher Assignee
	Comment 21 • 21 years ago

-> me

	Jim Dunn
	Comment 22 • 21 years ago

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

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

	Darin Fisher Assignee
	Comment 23 • 21 years ago

simon and pav may have opinions on this...

	Stuart Parmenter
	Comment 24 • 21 years ago

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

	Darin Fisher Assignee
	Comment 25 • 21 years ago

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.

	chris hofmann
	Comment 26 • 21 years ago

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

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

	Darin Fisher Assignee
	Comment 27 • 21 years ago

fixed-on-trunk

	Darin Fisher Assignee
	Comment 28 • 21 years ago

ok, see bug 218861 for redesign work.

	Oleg Sidletskiy
	Comment 29 • 21 years ago

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+

	Michael Lefevre
	Comment 30 • 21 years ago

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.

	Jon Henry
	Comment 31 • 21 years ago

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

	dominik.tappe
	Comment 32 • 21 years ago

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

	Lewis Jardine
	Comment 33 • 21 years ago

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.

	Robert Accettura [:raccettura]
	Comment 34 • 21 years ago

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

or is it a different bug?

Feels very slow in 1.5

	Jesse Ruderman Reporter
	Comment 35 • 21 years ago

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

	Robert Accettura [:raccettura]
	Comment 36 • 21 years ago

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