427042 - pegged CPU and rendering delay while displaying list of PNGs

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P4)

Description

[Mark Caudill]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

It seems, as far as I can tell, that Firefox 3 (I've tested B4 and B5) have a significant delay rendering images (or possibly just PNG images) while it's going through the HTTP request -and- the window is visible.  If the page does not render each image one after another, it takes 1 second.  If the page has to render each one serially, it takes >1second each image.  See my link for reproducing.  Keep in mind this isn't a problem if the images are cached (so clear cache between refreshes)!  I'm call this major because it significantly degrades the user experience.

Reproducible: Always

Steps to Reproduce:
1. Visit link
2. Watch results
3. Clear cache, try again
Actual Results:  
Loaded each image 1 at a time for upwards of 1 second.  I let 10 of them load, then minimized the window and restored (took 1 second total) and all images were done loading (>40?).

Expected Results:  
Loaded all the images

none

Comment 1

[Mark Caudill]

Forgot to mention that the CPU is pegged while loading these images.

Comment 2

[Mark Caudill]

I couldn't notice this issue with other lists of images (eg gif or jpg), but may not have done enough testing. (see http://www.famfamfam.com/lab/icons/mini/ as example).  PNG related, changing notes.

Comment 3

[Matthias Versen [:Matti]]

I can confirm this on vista with a 1 day old Seamonkey trunk.
The images in the given URL are rendert one by one but if the rendering is outside of the current view, it loads a lot faster

Comment 4

[Peter Weilbacher]

Same thing happends with SeaMonkey trunk on Linux.

Comment 5

[Mark Caudill]

This is still a problem with Firefox 3 final.  I think this should be a blocker for 3.1 due to the severity of the problem.  This really degrades the experience and bogs the CPU down in a way that should not be acceptable in this time and age.  Getting this fixed sooner rather than later is advisable.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

CPU is likely pegged because of the constant repainting; not a blocker, would be nice to optimize.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

I can't reproduce this with Firefox 3.0 on OS X or on Ubuntu 8.10 in a Parallels VM. However, I'm on fast machine with fast connection. How noticeable is the problem? Is the UI sluggish during the painting?

Comment 8

[Jeff Muizelaar [:jrmuizel]]

It looks like I can sort of reproduce this in a vista vm. The page draws much faster when it is not visible.

Comment 9

[Mark Caudill]

Even on a brand new computer with good GPU/CPU/RAM, this problem occurs on XP.  I have also noticed it on my macbook with osx.  The problem is very noticeable.  The UI is sluggish, but that depends on the amount of PNGs on the page (hence how long the rendering itself takes).

Jeff, I'm unsure of why it'd be less problematic in a VM, but it may have something to do with CPU utilization throttling in VMs.

Comment 10

[RNicoletto]

I can't reproduce this with Firefox 3.0.10 on Windows XP.

Comment 11

[Mark Caudill]

I'm not sure when this was fixed but it no longer seems to be terrible in Firefox 24.