pegged CPU and rendering delay while displaying list of PNGs

RESOLVED WORKSFORME

Status

()

defect
P4
normal
RESOLVED WORKSFORME
11 years ago
6 years ago

People

(Reporter: ninjainvisible, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

()

Reporter

Description

11 years ago
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
Reporter

Comment 1

11 years ago
Forgot to mention that the CPU is pegged while loading these images.
Reporter

Comment 2

11 years ago
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.
Severity: major → blocker
Flags: blocking-firefox3?
Version: unspecified → Trunk
Severity: blocker → major
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
Status: UNCONFIRMED → NEW
Component: General → GFX: Thebes
Ever confirmed: true
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → thebes

Comment 4

11 years ago
Same thing happends with SeaMonkey trunk on Linux.
OS: Windows XP → All
Reporter

Updated

11 years ago
Hardware: PC → All
Reporter

Updated

11 years ago
Summary: substantial rendering delay while displaying list of certain images → pegged CPU and rendering delay while displaying list of PNGs
Reporter

Comment 5

11 years ago
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.
Severity: major → blocker
Flags: blocking1.9.1?
CPU is likely pegged because of the constant repainting; not a blocker, would be nice to optimize.
Severity: blocker → normal
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P4
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?
It looks like I can sort of reproduce this in a vista vm. The page draws much faster when it is not visible.
Reporter

Comment 9

11 years ago
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

10 years ago
I can't reproduce this with Firefox 3.0.10 on Windows XP.
Reporter

Comment 11

6 years ago
I'm not sure when this was fixed but it no longer seems to be terrible in Firefox 24.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.