Re: Images & RAM consumption [was: Is SM2 mail a slug...]

Joe Drew <[email protected]>
Newsgroups gmane.comp.mozilla.devel.os2,gmane.comp.mozilla.devel.dom
Message-ID <[email protected]>
On 2009-12-18 7:03 PM, Boris Zbarsky wrote:
> On 12/18/09 3:04 PM, Felix Miata wrote:
>> I'm no programmer, but over many years of Mozilla development I've
>> spent a
>> lot of time hanging out in the core Moz devs IRC channels, and have
>> been able
>> to comprehend quite a bit of their discussion. IIUC, Ilya is right
>> about this
>> - though it seems to make no sense to an core dev outsider, image
>> files are
>> just DOM objects converted on load to an internal format used by the
>> DOM, and
>> grow immensely during the conversion.
>
> For what it's worth, I believe we drop the decoded data off a timer now.
> And we're working on making the decoding itself lazy.

It's not possible to leave images compressed all the time, because you 
have to decompress to draw. And, as Boris says, we have to draw them 
frequently when we're scrolling.

We've mostly moved to a model where images are not decoded until they're 
drawn, and the decoded data is thrown away after a little while, but 
that still isn't entirely enabled (due to bugs), even on mozilla-central.

To see what's blocking that, take a look at the list of bugs marked with 
[decodeondraw] in their whiteboard field: 
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[decodeondraw]

Finally, even before "decode-on-draw" (which is more accurately named 
"asynchronous decoding"), we cache 5 MB of decoded images to speed up 
their redisplay. Those unused but cached images, like others, have their 
decoded data thrown away after 30 seconds.

Any further questions, please ask.

Joe
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.