386451 - Too much memory used by Thebes Images to display 4.5Mb Image

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Oleg Romashin (:romaxa)]

Attachment: valgrind massif output

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

Comment 1

[Oleg Romashin (:romaxa)]

Attachment: Valgrind massif HTML output

Comment 2

[Oleg Romashin (:romaxa)]

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         

Comment 3

[Oleg Romashin (:romaxa)]

Attachment: Opera Massif postscript Output

Comment 4

[Oleg Romashin (:romaxa)]

Attachment: Opera Massif HTML output

Comment 5

[Oleg Romashin (:romaxa)]

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.... :(

Comment 6

[Oleg Romashin (:romaxa)]

Attachment: GTK2 Build Postscript Massif Output

Comment 7

[Oleg Romashin (:romaxa)]

Attachment: GTK2 build Massif HTML

Comment 8

[Stuart Parmenter]

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

This is on purpose.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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...

Comment 10

[Oleg Romashin (:romaxa)]

As I understand this picture is Black and White ;)

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 12

[Mike Schroepfer]

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

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 14

[timeless]

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

Comment 15

[Joe Drew (not getting mail)]

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.

Comment 16

[Johnny Stenback (:jst)]

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

Comment 17

[Justin Lebar (not reading bugmail)]

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

Comment 18

[Mike]

(In reply to Johnny Stenback (:jst, [e-mail]) 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.

Comment 19

[Justin Lebar (not reading bugmail)]

(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.

Comment 20

[Gregory Pappas [:gregp]]

In Firefox, I see 19MB content process, 6MB VRAM with this image open. In Chromium, I see 21MB content process, 7MB VRAM with this image open. Timothy, do you think its safe to close this bug?