For loading URL trunk gecko requires ~70 or more MB RAM. AMD 500MHz, 128RAM, NoSwap. Current Trunk Cairo Build: ./run-mozilla.sh ./TestGtkEmbed http://www.nih.gov/about/almanac/images/Johnson08091965a.jpg ................... progress_change_cb cur 655360 max 4463349 progress_change_cb cur 720896 max 4463349 The program 'gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 1848 error_code 11 request_code 53 minor_code 0) ................... PC with big RAM: Official FF Build thebes: VmPeak: 197308 kB VmSize: 120240 kB VmHWM: 99080 kB VmRSS: 22772 kB VmData: 87996 kB

Opera load this image without any problem and there are still a lot of memory... MemTotal: 127136 kB MemFree: 3732 kB Buffers: 1244 kB Cached: 37028 kB SwapCached: 0 kB Active: 92772 kB Inactive: 20908 kB HighTotal: 0 kB Mem: 127136k total, 124460k used, 2676k free, 1820k buffers Swap: 0k total, 0k used, 0k free, 41076k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2508 romaxa 15 0 74520 54m 9444 S 0.3 43.8 0:09.94 opera 2062 root 15 0 26628 8636 1680 R 2.3 6.8 1:07.99 Xorg 2165 romaxa 15 0 36700 8116 2168 S 1.3 6.4 0:16.35 gnome-terminal 2164 romaxa 15 0 17912 5092 2372 S 0.0 4.0 0:09.35 metacity

Old FF Build Gtk2: VmPeak: 120992 kB VmSize: 62724 kB VmHWM: 81804 kB VmRSS: 23376 kB VmData: 32964 kB - ! progress_change_cb cur 720896 max 4463349 - gfx/src/thebes progress_change_cb cur 4420749 max 4463349 - gfx/src/gtk According this log current thebes build Thebes build require much more memory for loading this picture.... :(

It will use exactly 78139776 bytes (5692*3432*4). Pre-cairo/thebes it would use 58604832 (5692*3432*3). This is on purpose.

That doesn't match the 70MB number cited in comment 0. And I thought we optimized images without an alpha channel to be stored in RGB24, at least on non-Windows. See gfxPlatform::OptimizeImage...

As I understand this picture is Black and White ;)

OptimizeImage sets the format to RGB24 -- the actual byte format is always 4 bytes per pixel. (Technically the enum should be XRGB32 vs. ARGB32, but cairo calls it RGB24...) We should at least trace allocations and see where they're coming from.

Re-noming just to see if there are any straightforward opts available for 1.9..

Nothing really straightforward; I'll mark this wanted, in case we have time after b2 -- the only thing I can think of is to always decode on draw for very large images, and maybe do it a tile at a time, though that would mean multiple decode passes to draw it once. We may also be able to store things in RGB24 in some cases and only expand out if we need to do other ops on them, but I don't know how that'll work with scaling. I'm not sure what Opera is doing on Linux, but opening that image in Opera 9 on win32 causes the opera process to go from about 18MB -> 76MB -- which is a 58MB difference, consistent with storing the image as packed RGB24.

vlad: tiles would be great, especially if they're limited to some function of something like quarter screen size or 200x200... our screen is 800x480. if you stored decoded tiles of 400x240, or up to 1600x960 they'd still be much smaller than the image in question and make us much happier. 200x200 might also be ok. for the worst case, it'd cost 15 tiles to show a single image on the screen

Nomming for someone to look at this in MemShrink. It's not clear whether we're wasting memory here; AIUI Cairo doesn't support packed RGB, though maybe it could be made to. There might be other things we can do here too.

Marking this a MemShrink:P3 to track this, but it doesn't seem like a super large win and also a lot of work.

I believe IE uses packed RGB, so I guess this meets the criteria for image-suck.

(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #16) > but it doesn't seem like a super large win I use FF nightly on Linux box with 1Gb RAM and integrated video. Browsing is fine, except pages with many images. FF puts system into "deep" swap - freeze for few minutes, while Opera works pretty well in that case.

(In reply to Mike from comment #18) > I use FF nightly on Linux box with 1Gb RAM and integrated video. Browsing is > fine, except pages with many images. FF puts system into "deep" swap - > freeze for few minutes, while Opera works pretty well in that case. That's not specifically this bug, but rather bug 660577.