long paint delay when restoring/focusing app with CMS enabled

RESOLVED FIXED

Status

()

Core
GFX: Color Management
P3
normal
RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: Peter6, Assigned: bholley)

Tracking

({perf})

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
blocking1.9 -
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101609 Minefield/3.0a9pre ID:2007101609

repro:
open FF and open a few tabs
open a few other apps and play around a bit
bring FF to the foreground (focus)

result:
it takes 5 -10 seconds before the app and content are painted.

The problem went away when Bug 296818 was backed out to investigate bug 399955
(Reporter)

Updated

11 years ago
Keywords: regression
(Reporter)

Comment 1

11 years ago
right Bug 296818 was relanded and the problem is back.

This is only visable if you use a sidebar, doesn't matter if it's the places sidebar, history sidebar or in my case the sidebar from the tabsidebar extension.
Flags: blocking1.9?
(Reporter)

Updated

11 years ago
Keywords: perf
(Reporter)

Updated

11 years ago
Summary: long delays painting the app when it's brought to the foreground. → long delays painting the app when it's brought to the foreground (when a sidebar is used).
(Reporter)

Comment 2

11 years ago
the presence of a sidebar makes it worse, but the problem is noticeable with the standard window aswell, possibly caused by the images in the bookmarks toolbar.
(The images in the sidebars seem to be the cause too)

btw i'm using XP on a T5600 duo , Ati X1450 and 2Gb of ram.
(Reporter)

Updated

11 years ago
Summary: long delays painting the app when it's brought to the foreground (when a sidebar is used). → long delays painting the app when it's brought to the foreground.
(Reporter)

Comment 3

11 years ago
It seems you need to browse a while first, apparently to make sure all the memory is filled. After that even if you use a single tab the delay is noticeable.

Comment 4

11 years ago
Is anyone else seeing this?  It shouldn't be 5-10 seconds to redecode...
(Reporter)

Comment 6

11 years ago
maybe this is a problem for laptops only that use the normal ram for graphics aswell.
I have been using a new profile for a few days just to see if it might be profile and/or extension related, it's not.
After 10-15 minutes of use, FF simply sux.
Even switching between tabs and opening/closing tabs takes up to 5 secs. 
If a closed tab contains animated flash the delay goes up to nearly 10 secs.

Comment 7

10 years ago
this should be blocking if people are seeing it... unfortunately I can't reproduce it on any of my machines :(
Flags: blocking1.9? → blocking1.9+
Priority: -- → P5
(Reporter)

Comment 8

10 years ago
settings:
gfx.color_management.enabled true
gfx.color_management.display_profile C:\\WINDOWS\system32\spool\drivers\color\kodak_dc.icm

once i disable the colormanagement the problem is gone.
(Reporter)

Comment 9

10 years ago
I'm not sure this should be blocking Bug 16769 or not ? 

Updated

10 years ago
Assignee: nobody → pavlov

Comment 10

10 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b3pre) Gecko/2007122815 Minefield/3.0b3pre

Bug does not seem to be affecting me. Last statement on this bug was 6 weeks ago: other platforms re-check?
(Reporter)

Comment 11

10 years ago
That's because my graph chip died, so can't test the problem

Comment 12

10 years ago
I can still see this problem with the 2008-01-10 trunk build.

1. gfx.color_management.enabled -> true; ...display_profile -> "" (=sRGB)
2. visit e.g. http://www.physics.drexel.edu/~goldberg/projections/
3. scroll right down so pictures are out of sight, wait for a while
4. press Page Up a few times: each step takes 5-10 seconds
5. switch to this bug in another tab, wait for a while.
6. selecting the original tab takes about 10 seconds.

If I set color_management.enabled -> false, steps 4 and 6 are both basically instant, maybe a tiny bit lumpy.

System: 384MB P3-600, about 80-100MB physical RAM free; GeForce 256 32MB; WinXP; Comodo Firewall/AV.

Comment 13

10 years ago
going to minus this since we aren't shipping with color correction on by default -- we'd like to fix this but can't easily reproduce it.  we know littlecms needs to be made a bit faster and we'll likely do that in the next release
Flags: wanted1.9.0.x+

Updated

10 years ago
Flags: tracking1.9+ → blocking1.9-

Comment 14

10 years ago
I found this bug obviously, when the windows explorer copying the huge files took the 100% CPU resources.
It's easy switching to other apps, or starting another explorer.
But Fx takes a few seconds to bring it back to the foreground.

Even I have the Pentium 4 2.4GHz /w HT, 1G RAM and GeForce Fx5500(128MB) on WinXP SP2.

Generated: Sat Mar 15 2008 08:24:15 GMT+0800
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031412 Minefield/3.0b5pre

Updated

10 years ago
Blocks: 418538

Comment 15

10 years ago
See forum thread: http://forums.mozillazine.org/viewtopic.php?f=7&t=688285

Firefox aggressively frees decompressed images after only about 15 seconds, even with the tabs open and the user still on the page. This introduces some lag when scrolling or switching tabs.

As noted above, the problem is greatly exacerbated by turning on color management, as this appears to reduce decompression performance by 10x for some larger images. See https://bugzilla.mozilla.org/show_bug.cgi?id=435628 for more details, and http://qucs.sourceforge.net/tech/node101.html for some good example images.

I suggest that the algorithm for reclaiming memory needs to be tweaked to hold image data longer for open tabs, and still longer for the tab currently being viewed. This will improve apparent performance with and without the color management problem, and should still avoid the appearance of memory leaks.

Comment 16

10 years ago
If the bahavior is based upon the fact that firefox drops the uncompressed image after only a few seconds adding a setting (e.g about:config) can help to improve it for people which deal regularly with large images. For the future i would implement a learning algorithm which increases the timeout when images often need to be uncompressed.
I'm seeing this issue with http://www.starcraft2.com/features/planets/char.xml
Flags: wanted1.9.1?
Flags: blocking1.9.1?
(Assignee)

Comment 18

10 years ago
Confirmed.

I ran into this issue while doing some other perf analysis on CM. If I leave the app in the background for a while with a big CMed imaged loaded, it takes a noticeable amount of time. I managed to Shark it, and it looks like it spent about 50% of that time redoing all the matrix multiplication and interpolation for color management, 8.4% in jpeg_idct_islow, 8.1% in the vector operation from DrawImage, 7.2% in decode_mcu (jpeg_read_scanlines), and 3% in ycc_rgb_convert (jpeg_read_scanlines).

Stuart - does this mean it's doing all the image decoding again? Is this the expected result of our caching policy?

This problem should be helped by my work on bug 444661, which should get rid of nearly half of that 50% color management overhead (LUT interpolations). The matrix multiplications may be much more difficult to deal with though.

Editing this bug so that it shows up under the perf regression bug for CM.
Assignee: pavlov → bholley
Blocks: 444659
No longer blocks: 296818, 418538
(Assignee)

Comment 19

10 years ago
CCing Joe given his work on image caching
Severity: major → normal
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Keywords: regression
Priority: P5 → P3
Summary: long delays painting the app when it's brought to the foreground. → long paint delay when restoring/focusing app with CMS enabled

Updated

9 years ago
Component: ImageLib → GFX: Color Management
QA Contact: imagelib → color-management
(Assignee)

Comment 20

8 years ago
This is just a known side effect of our old discarding strategy. This should be fixed by the stuff over in bug 435296 once we eventually get discarding switched back on. Resolving fixed.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.