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

Status: NEW

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

Description

[Alex Firestone]

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.

Comment 1

[Simon Porter]

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.

Comment 2

[Glenn Randers-Pehrson]

This is probably a dupe of bug #400075

Comment 3

[Edward Asquith]

See http://forums.mozillazine.org/viewtopic.php?f=7&t=688285

Comment 4

[Alex Firestone]

Updated the title to reflect the issue also occurring with interlaced (multi-pass) PNG images.

Comment 5

[Alex Firestone]

Since work on the color management bugs seems to be going quite slow, may as well aim for the Firefox 3.2 release instead.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Does this still happen now that we have qcms?

Comment 7

[Alex Firestone]

(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.

Comment 8

[Manoj]

keyword SNAPPY?

Comment 9

[Alex Firestone]

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.

Comment 10

[malch]

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

Comment 11

[Sylvestre Ledru [:Sylvestre]]

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

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:aosmond, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 13

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.