bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Resized (scaled) images causes slow scrolling (dimensions in HTML do not match intrinsic dimensions)



Core Graveyard
Image: Painting
16 years ago
8 years ago


(Reporter: Jerry Baker, Unassigned)


(Blocks: 1 bug, {perf, testcase})

Windows XP
perf, testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(5 attachments)



16 years ago
2002082109 trunk

Mozilla has some major performance problems with resized images. I think this is
the root of most of the scrolling complaints being entered into Bugzilla now
that background image tiling has been improved.

Comment 1

16 years ago
Created attachment 96275 [details]
PNG used in scrolling attachment below

Comment 2

16 years ago
Created attachment 96276 [details]
Scrolling demo

Load this attachment and size your Mozilla window so that vertical scrolling is
required. Watch the chop when you scroll.


16 years ago
Keywords: perf, testcase

Comment 3

16 years ago
works for me

Comment 4

16 years ago
Created attachment 96283 [details]
Scrolling demo with same NON-resized images

Comment 5

16 years ago
Scrolling with resized images is much slowed than scrolling with images in
original size for me - 2002082109/trunk/W2K

Comment 6

16 years ago
All I have to do is use the mouse wheel to scroll a few lines and Mozilla pegs
the CPU at 100%.

Comment 7

16 years ago
I suppose this should be under Image: GFX.
Component: Image: Layout → Image: GFX


16 years ago
Depends on: 170272

Comment 8

16 years ago
This is related to  bug 170272.

Comment 9

16 years ago
Just a note that bug 170272 is marked fixed and this bug has not improved.

Comment 10

16 years ago
*** Bug 179662 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
*** Bug 183168 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
I believe this is a dupe of bug 159512.

Comment 13

15 years ago
*** Bug 197721 has been marked as a duplicate of this bug. ***

Comment 14

15 years ago
Also affects Phoenix.

Comment 15

15 years ago
I can confirm that this is a big problem for me on Windows 2000. Seems that the
resizing algorithm has pretty poor performance. Would it be possible to resize
just the once, and cache the resized image for future use? It may be a
relatively simple workaround until the algorithm is considerably improved.

Comment 16

15 years ago
Please make sure that you are using the newest video drivers for your video card.

Comment 17

15 years ago
That's not always possible. Newest NVidia drivers blue-screen my XP. It took a
while to trace the dump to the NVidia drivers. And, if my recollection serves
me, this problem was not any better. In fact, I had to turn video acceleration
down with the latest drivers to stop some really laggy behavior in mail/news.

Comment 18

15 years ago
If you turned down acceleration, then logically wouldn't that be an explanation
for resized images being slow with Mozilla?

Comment 19

15 years ago
No. I am not using those drivers anymore, and as such my acceleration is turned
back up. My point was that the newer drivers had more problems in Mozilla than
the drivers I am using.

Comment 20

15 years ago
*** Bug 210000 has been marked as a duplicate of this bug. ***

Comment 21

15 years ago
I tried to reproduce this problem, and also the problem mentioned in bug 210000.
I could only reproduce it on http://gamer.vip.hr/ - is this the same issue?

Comment 22

15 years ago
This is still reproduceable on any page that has resized images using the latest
trunk builds.


15 years ago
Blocks: 100951


15 years ago
Summary: Resizing images causes poor performance (scrolling) → Resizing images causes slow scrolling (dimensions in HTML do not match intrinsic dimensions)

Comment 23

15 years ago
*** Bug 200814 has been marked as a duplicate of this bug. ***

Comment 24

15 years ago
This bug seems to have become noticeably worse in the last few weeks. Using a
917 trunk build, even moving the cursor around on a page with a resized image
pegs the CPU.

Comment 25

15 years ago
*** Bug 182666 has been marked as a duplicate of this bug. ***

Comment 26

15 years ago
*** Bug 224807 has been marked as a duplicate of this bug. ***

Comment 27

15 years ago
*** Bug 228872 has been marked as a duplicate of this bug. ***
*** Bug 183168 has been marked as a duplicate of this bug. ***

Comment 29

14 years ago
*** Bug 238423 has been marked as a duplicate of this bug. ***

Comment 30

14 years ago
I filed bug #238423.  That was a dupe of this one (sorry), but for some reason 
I didn't see this when I searched.

Here's the test case I set up:

Comment 31

14 years ago
I can confirm this on Win98. Till now, it happened only in 24bit mode. I have
now tried Firefox 20040423 and Mozilla 1.7RC1 and it now happens also in 16bit
mode. It is horribly slow when rendering the image AND also when scrolling. I
have a 200MHz machine therefore I can easily see the difference.

Comment 32

14 years ago
Ok, I can reproduce it on all my machines, ranging from Win95 to Win2000 (all
16bit). I have tracked down the slowness to the precise point when an image is
not completelly on screen (or does not fit) and I scroll it in the direction so
that new parts of it are revealed. Once the image is fully visible, the
scrolling becomes fast. Also when the image is scrolling out of screen (or the
viewport). Therefore, displaying of new parts of an image is the problem here.

OS should be changed to All Windows.
when the image is all on-screen, scrolling is fast because we don't have to
repaint the image at all, we're just copying the screen pixels around.

Comment 34

14 years ago
Yes, that's what I wanted to say. Other comments only mention that 'scrolling is
slow', which is not really true. Only special cases of scrolling (the content
visible) is slow.

Comment 35

12 years ago
*** Bug 323762 has been marked as a duplicate of this bug. ***


12 years ago
Summary: Resizing images causes slow scrolling (dimensions in HTML do not match intrinsic dimensions) → Resized (scaled) images causes slow scrolling (dimensions in HTML do not match intrinsic dimensions)
*** Bug 326239 has been marked as a duplicate of this bug. ***
*** Bug 333238 has been marked as a duplicate of this bug. ***
*** Bug 340656 has been marked as a duplicate of this bug. ***

Comment 39

12 years ago
*** Bug 342654 has been marked as a duplicate of this bug. ***

Comment 40

12 years ago
Hi again, the real consistency seems to be with large images, say images with dimensions like 1024x768, that has been scaled down using code like this.....
<img src="myimage.jpg" width="100" height="90" alt="My Image">
to visually appear smaller on screen.

Also, it can simply just include links to large images as indicated in this example.


Just hovering my mouse in the Caribbean Satellite link above, after it has loaded, gives the mouse a very heavy feel. Even hovering it's tab (when multi-tab is used) and it is not the focus tab, gives it a heavy feel.

In terms of the scrolling complaints, it only manifest when scrolling down a page to meet a large image or a large image scaled down using the img/width/height html code.

My recommendation - Use better scaling algorithms, a good ultra fast free library (not using open GL or gdi+) is the Gr32 Library - however it is a Delphi Library.


My PC Specs...
CPU: AMD Athlon(tm)XP 2400+ 
RAM: 768 Mbytes
Antivirus: Avast
Other : MSN, Yahoo, WinAMP, Google Desktop Search, MySQL Database - all active.

Comment 41

12 years ago
I have decided to add this comment here, because other examples in this thread just dont show the effect on my system, mostly because they are to small.

When i scroll jpgs on homepages which are scaled down via "scaleImg()" for
example, the CPU load rises to 100% no matter how fast i scroll. The redraw of
the picture entering the screen is very choppy. The same happens when moving a window in front of the jpg.

Here is an example jpg i painted and uploaded myself.


The choppy scrolling does not happen when the the windows graphics hardware
acceleration is turned down one notch. (under view properties -> problems). The
CPU load is lower then, more like 60%.

It is propably important that the problem came first to my attention after i
changed to an ATI graphics card from a Nvidia GF 4. Older ATI drivers show the
same problem.

Computer config:
XP prof SP2
A64 3500+
Sapphire X800GT AGP graphics with catalyst 6.5
*** Bug 358473 has been marked as a duplicate of this bug. ***

Comment 43

11 years ago
Created attachment 253704 [details]
JPEG image used in JPEG testcase

Comment 44

11 years ago
Created attachment 253706 [details]
JPEG testcase

This is the testcase from http://www.dillout.de/share/test.html which is discussed in MozillaZine thread http://forums.mozillazine.org/viewtopic.php?t=513497
QA Contact: tpreston → image.gfx
Duplicate of this bug: 372569


11 years ago
Assignee: pavlov → nobody

Comment 46

11 years ago
It all seems fine to me - minor CPU usage here and there.
Perhaps everyone who has a problem should be saying
1) how much ram do you have 
2) what speed is your CPU

Comment 47

10 years ago
Jerry, still see your problem with trunk build?

attachment 253706 [details] is smooth for me, but high cpu. Original testcase smooth.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008040606 Minefield/3.0pre

Comment 48

10 years ago
I don't see an issue using, but I do not use trunk builds any longer so I cannot comment on the trunk.
I'm the author of the ImageTweak extension and I'm noticing something odd while testing it in Fx3 (don't know about Fx2, I'm not using it anymore).
My extension among other things allows the user to move and zoom images contained within nsImageDocument. This is done by making the img absolutely positioned, and then appropriately modifying its position and dimensions.
The odd thing is that, even for large images, when the image is at 100% zoom (i.e. not resized), the scrolling works smoothly. When it is zoomed (not only when enlarged, *but also when reduced*) instead the image (this depends on the image size, obviously) is drawn at most a couple times per second (image: 3840x2400 png24, screen size 1920x1200 32bpp, cpu: Athlon64 3200+, ram: 1GB DDR533).

Comment 50

9 years ago
This appears to be resolved (at least for me) in current trunk builds.  It's
smooth as butter and quite fast now:  Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.9.2a1pre) Gecko/20090210 Minefield/3.2a1pre (.NET CLR 3.5.30729)

Duplicate of this bug: 488302

Comment 52

9 years ago
All testcases are WFM.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090427 Shiretoko/3.5b4

Comment 53

9 years ago
WFM based on comment 50 and 52 and testing with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME


8 years ago
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.