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

[Felix Miata]

Are you implying that FF stores image objects uncompressed?

??? Do you know ANY graphic program which does otherwise?

FF is no "graphics program". The only reason why graphics programs store
images uncompressed is that it is necessary for manipulation.
FF just displays images and it doesn't make any sense to decode all
images to uncompressed and keep them in memory uncompressed

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.

[William L. Hartzell]

Post by Felix Miata

Are you implying that FF stores image objects uncompressed?

??? Do you know ANY graphic program which does otherwise?

FF is no "graphics program". The only reason why graphics programs store
images uncompressed is that it is necessary for manipulation.
FF just displays images and it doesn't make any sense to decode all
images to uncompressed and keep them in memory uncompressed

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.

Why convert them? Could not the rendering be done at display time, ie
during WM_Paint?
--
Bill
<Thanks, a Million>

[Boris Zbarsky]

Why convert them? Could not the rendering be done at display time, ie
during WM_Paint?

Turns out that if done naively this sends painting performance (e.g.
scrolling) all to hell.

-Boris

[Boris Zbarsky]

Post by Felix Miata
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.

-Boris

[Joe Drew]

Post by Boris Zbarsky

Post by Felix Miata
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