© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
> then hit this website and watch how quickly RAM usage for pixmap storage is
> allowed to climb:
I don't see how timing out images within seconds will help that problem. A solid-color PNG image size scales basically as the log of the decoded image size. So a fairly small actual image can easily fill up whatever size memory you happen to have once decoded.
Frankly, I don't think bug 395260 is a duplicate of this bug. What's needed to fix this bug, in my opinion, is to evict "unused" decoded images, for some definition of "unused". A good one might be an image that has not had its actual image data accessed (via the DOM or by being painted or whatever) for some period of time. The "unused" qualifier is almost certainly needed to prevent unacceptable impact on DHTML, pageload, and scrolling performance.
What's needed to fix bug 395260, again in my opinion, is a hard cap on the amount of pixmap storage we'll allocate. That should be a separate configuration option from the fix for this bug, and someone running Gecko in an environment where server memory is constrained could use that option. In such an environment, as you have said, a severe performance hit, or even not seeing the image at all, is much more acceptable than crashing the X server.
I do think that we should consider defaulting this hard cap to some fraction of the total physical memory in the machine. Not rendering images at all seems preferable to having to swap to paint them. But again, I think that would best be handled in bug 395260.