Kan-Ru Chen [:kanru] (UTC+9) Reporter
	Description • 10 years ago

+++ This bug was initially created as a clone of Bug #945161 +++

With decode on draw we still cache the image source in memory for future decoding. This could use a lot of memory if the image source is big.

Store the image source in file cache or download them only when needed.

	Andreas Gal :gal
	Comment 1 • 10 years ago

Doesn't the OOM handler throw this cache out? If so, why eagerly avoid caching?

	Kan-Ru Chen [:kanru] (UTC+9) Reporter
	Comment 2 • 10 years ago

(In reply to Andreas Gal :gal from comment #1)
> Doesn't the OOM handler throw this cache out? If so, why eagerly avoid
> caching?

No, we only discard the decode image but not the source data. When the source data is downloaded it resides in memory until RasterImage is deleted. Try http://www.boston.com/bigpicture on the phone and you will know what I mean.

	Thinker Li [:sinker]
	Comment 3 • 10 years ago

Could we back the memory with the image file?

	Kan-Ru Chen [:kanru] (UTC+9) Reporter
	Comment 4 • 10 years ago

(In reply to Thinker Li [:sinker] from comment #3)
> Could we back the memory with the image file?

Seth said that we could see if we are able to pin a necko cache for a period of time, perhaps bound to the docShell's life time.

	Seth Fowler [:seth] [:s2h]
	Comment 5 • 8 years ago

(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #4)
> Seth said that we could see if we are able to pin a necko cache for a period
> of time, perhaps bound to the docShell's life time.

What we should be doing is ensuring that we don't have a copy of the image's source data in memory *both* in the HTTP cache and in the ImageLib cache. It makes sense, for this reason, to pin the HTTP cache entry and read it back out of the HTTP cache if needed.

We almost certainly do not want to have *zero* copies of the image's source data in memory, though. That makes downscale-during-decode impossible and also means that we can never discard the image. Since the decoded form of images is *huge* compared to the source data, that is a net loss in virtually every scenario.

	Sylvestre Ledru [:Sylvestre]
	Comment 6 • 6 years ago

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