Open Bug 386451 Opened 13 years ago Updated 7 years ago

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

Categories

(Core :: Graphics, defect, P3)

x86
Linux
defect

Tracking

()

People

(Reporter: romaxa, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: memory-footprint, Whiteboard: [MemShrink:P3])

Attachments

(6 files)

Attached file 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
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.... :(
Flags: blocking1.9?
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...
Keywords: footprint
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.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Re-noming just to see if there are any straightforward opts available for 1.9..
Flags: blocking1.9- → blocking1.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.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Priority: -- → P3
Whiteboard: [wanted-1.9]
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.
Whiteboard: [memshrink]
Marking this a MemShrink:P3 to track this, but it doesn't seem like a super large win and also a lot of work.
Whiteboard: [memshrink] → [MemShrink:P3]
I believe IE uses packed RGB, so I guess this meets the criteria for image-suck.
Blocks: 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.
You need to log in before you can comment on or make changes to this bug.