[cairo] PDF memory usage?

[Ralph Giles]

On Wed, Jun 10, 2009 at 12:58 PM, Ian Britten<britten at caris.com> wrote:

> Unfortunately, there doesn't seem to be a way with Cairo to
> intercept the pointer dereference of the raw image buffer, so you
> can't use this technique, and thus have to keep everything in
> memory...

No, that's why it doesn't help with 32 bit addressing limitations. My
suggestion was that by using a memory-mapped file, you could do that
with the cairo_surface_set_mime_data() approach (and maybe with
cairo_image_surface_create_for_data?) because the operating system
kernel *can* intercept pointer dereferences, saving physical memory.

There is an internal stream object in cairo. To handle images that
don't fit in the addressable memory, you'd need extend that to support
'large' offsets, export it as part of the public api and add a
cairo_surface_add_mime_stream() interface. I believe the current
whole-buffer approach was chosen for api simplicity. You'd have to
convince the cairo devs your use case justifies adding something more
complicated.

Actually, looking more closely, I notice that get/set_mime_data uses
'unsigned int' for length, so this won't work for images larger than 4
GB (compressed) even on LP64 systems like Linux x86_64, never mind
Win64. Maybe you should try ghostscript :P.

 -r