Open Bug 435628 Opened 12 years ago Updated Last year

100% CPU on Progressive JPEG & Interlaced PNG when gfx.color_management (qcms) is enabled

Categories

(Core :: GFX: Color Management, defect, P3)

defect

Tracking

()

People

(Reporter: cyber.spamage, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: memory-footprint, perf, Whiteboard: [Snappy:P3])

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

When viewing a progressive (multi-pass) jpeg CPU usage will hit 100% and the browser will become unresponsive until the image is loaded when gfx.color_management is enabled.

For normal (single pass) jpegs this problem doesn't occur.

To give you an idea, with gfx.color_management.enabled=false a progressive jpeg 2205x2136 will load in less than a second with about 50% CPU usage. With gfx.color_management.enabled=true that same image will take 7-10 seconds to load with 100% CPU usage.

Reproducible: Always

Steps to Reproduce:
1. Set gfx.color_management.enabled to True
2. Restart Firefox
3. Load a large progressive (multi-pass) jpeg (say 2048x2048 or larger)
Actual Results:  
100% CPU usage and unresponsive browser until the image is loaded.

Image takes up to 1000% (10x) longer to load than with gfx.color_management.enabled=false

Expected Results:  
Browser doesn't use 100% CPU and progressive jpegs take no more than 100% longer to load when gfx.color_management.enabled=true.

This problem happens with Firefox 3.0 RC1 as well as the latest 3.0 nightly builds.
Keywords: footprint, perf
Version: unspecified → 3.0 Branch
I an confirm this bug with a PNG 1770x1310. Apart from the above description of the issue when you leave the tab containing the image and then return it hangs every time.
Component: General → GFX
Product: Firefox → Core
Version: 3.0 Branch → Trunk
QA Contact: general → general
Blocks: 418538
This is probably a dupe of bug #400075
Flags: blocking1.9.0.1?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Blocks: 444659
Summary: 100% CPU on Progressive JPEG when gfx.color_management.enabled=true → 100% CPU on Progressive JPEG & Interlaced PNG when gfx.color_management.enabled=true
Updated the title to reflect the issue also occurring with interlaced (multi-pass) PNG images.
Blocks: 455077
Flags: wanted1.9.1?
Flags: wanted1.9.1? → wanted1.9.1+
Priority: -- → P2
Flags: wanted1.9.2?
Since work on the color management bugs seems to be going quite slow, may as well aim for the Firefox 3.2 release instead.
Component: GFX → GFX: Color Management
QA Contact: general → color-management
Does this still happen now that we have qcms?
(In reply to comment #6)
> Does this still happen now that we have qcms?

I just tested a large 3000x4000 progressive jpeg with qcms and it seems the behavior mimics lcms. 100% CPU and the browsers becomes unresponsive (many seconds) until the image is fully loaded.
keyword SNAPPY?
I guess it wouldn't hurt. Added [Snappy:P3] to the whiteboard and changed the title slightly in hope that it'll help this bug get rediscovered.
OS: Windows XP → All
Hardware: x86 → All
Summary: 100% CPU on Progressive JPEG & Interlaced PNG when gfx.color_management.enabled=true → 100% CPU on Progressive JPEG & Interlaced PNG when gfx.color_management (qcms) is enabled
Whiteboard: [Snappy:P3]
I believe this bug is still present on Windows and most Linux builds.

However, there is some evidence that the problem:

1. Arises only on CPU's without SSE4.1 support.

2. May have been fixed with the Firefox 12 build in the Mepis 11 community repo.

See also #752254:

https://bugzilla.mozilla.org/show_bug.cgi?id=752254
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.