In both Firefox Aurora and Firefox Nightly (15.0a1 (2012-06-04)), the following demo consumes around 3.3gb of heap once loaded: http://_hildr.luminance.org/Lumberjack_Broken/Lumberjack.html Furthermore, about:memory (which only works if I open it in a new window, because changing tabs frees *all* the image memory - WTF WTF WTF) reports that nearly all the memory is being used by images (see attachment). In Chrome, this demo uses around 450MB of memory total (of course, they could be cheating or hiding usage or something) - and I manually converted all the textures from png/jpeg to BMP to get a rough estimate of how much memory is needed to store them in raw 24-bit RGB - and ended up with roughly 440MB of BMP files, which means that the total memory usage to store them in 32-bit RGBA shouldn't be much higher than 586MB. This seems to indicate that Firefox is using roughly 5x the necessary amount of RAM to store these images. Even if some of this memory could be accounted to mipmaps, it's still way too much. P.S. WTF #2: The out-of-memory condition created by this demo causes Firefox to break in all sorts of ways - loading assets from cache/network silently fails with no error message, rendering of particular images fails silently or renders black/white, etc. I would have expected something slightly more sensical there. If you get lucky, you do get NS_ERROR_OUT_OF_MEMORY from calls, but it is not remotely consistent.

OK, I have to revise this: The tool I used initially to measure the raw size of the textures is broken. I went and re-converted all the images using imagemagick, making sure that the outputs weren't being compressed and that no format conversion was happening behind my back (I used irfanview originally and it silently did both things to the images, and also silently failed to convert some of them - both of these things lowered the total size). The outputs from imagemagick, when you sum up the file sizes, roughly align with the amount of memory used by Firefox for this demo - so this issue is probably just bug #683290 combined with really weird OOM behavior and how difficult it is to actually identify how much memory is being used for images and which images. P.S. To dig further into this, I used a conditional breakpoint in VS2010. I set the breakpoint on gfxImageSurface.cpp line 111, and used the 'When Hit' option to make it log the following string: 'gfxImageSurface(size=({size.width},{size.height}), format={format}, bytes={mSize.height * mStride})' That gave me a dump of all the image surfaces allocated along with their format/size and I was able to match that up to the actual images and everything looked OK.

I wonder if it would make sense to expose some image information in about:memory or elsewhere. I guess it is usually clear enough what page it comes from.

(In reply to Andrew McCreight [:mccr8] from comment #2) > I wonder if it would make sense to expose some image information in > about:memory or elsewhere. I guess it is usually clear enough what page it > comes from. You mean, some more detailed image information, like "this tab is using the following 10 images with the following sizes"? That could be interesting, I guess. But it sounds like we should just close this bug, and possibly file a new one per comment 2.