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