37.81 KB, image/png
1.07 KB, text/html
1.08 KB, text/html
8.56 KB, image/jpeg
7.87 KB, text/html
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.
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.
works for me
Scrolling with resized images is much slowed than scrolling with images in original size for me - 2002082109/trunk/W2K
All I have to do is use the mouse wheel to scroll a few lines and Mozilla pegs the CPU at 100%.
I suppose this should be under Image: GFX.
This is related to bug 170272.
Just a note that bug 170272 is marked fixed and this bug has not improved.
*** Bug 179662 has been marked as a duplicate of this bug. ***
*** Bug 183168 has been marked as a duplicate of this bug. ***
I believe this is a dupe of bug 159512.
*** Bug 197721 has been marked as a duplicate of this bug. ***
Also affects Phoenix.
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.
Please make sure that you are using the newest video drivers for your video card.
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.
If you turned down acceleration, then logically wouldn't that be an explanation for resized images being slow with Mozilla?
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.
*** Bug 210000 has been marked as a duplicate of this bug. ***
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?
This is still reproduceable on any page that has resized images using the latest trunk builds.
*** Bug 200814 has been marked as a duplicate of this bug. ***
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.
*** Bug 182666 has been marked as a duplicate of this bug. ***
*** Bug 224807 has been marked as a duplicate of this bug. ***
*** Bug 228872 has been marked as a duplicate of this bug. ***
*** Bug 183168 has been marked as a duplicate of this bug. ***
*** Bug 238423 has been marked as a duplicate of this bug. ***
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: http://www.axonchisel.net/etc/test/200403-firefox-img-scroll-bug-test.html
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.
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.
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.
*** Bug 323762 has been marked as a duplicate of this bug. ***
*** 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. ***
*** Bug 342654 has been marked as a duplicate of this bug. ***
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. http://maps.weather.com/images/sat/caribsat_720x486.jpg 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. http://www.graphics32.org/wiki/pub/page/Main/Graphics32 My PC Specs... OS: WinXP SP2 CPU: AMD Athlon(tm)XP 2400+ RAM: 768 Mbytes Antivirus: Avast Other : MSN, Yahoo, WinAMP, Google Desktop Search, MySQL Database - all active.
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. http://img222.imageshack.us/my.php?image=testbild17yl.jpg 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+ 1 GB RAM Sapphire X800GT AGP graphics with catalyst 6.5
*** Bug 358473 has been marked as a duplicate of this bug. ***
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
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
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
I don't see an issue using 188.8.131.52, 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).
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) ID:20090210050102 ~B
All testcases are WFM. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090427 Shiretoko/3.5b4
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