[cairo] JPEG support patch
Bill Spitzak
spitzak at d2.com
Wed Jan 17 17:59:06 PST 2007
Actually DevIL is the library I was thinking of when I was trying to
make a proposal for a new cairo pattern t.
Perhaps Cairo can just require DevIL. Several other libraries do such as
Ogre (which is where I discovered it) so this may not be too much of a
problem. For the pdf output that originally initiated this discussion,
it would still be a good idea to add a new cairo_pattern_t that wraps
DevIL. The reason for this is so it can be set as a source in the pdf
backend, and the pdf backend can recognize it is a DevIL image, get at
the DevIL data and figure out it is a jpeg, and from there extract the
compressed jpeg data directly.
DevIL also has the ability to directly produce an OpenGL texture, which
might be useful for the Glitz backend when it recognizes source patterns.
It might be a good idea to leave "DevIL" out of the api so that image
file back end could be changed to a different library. However I expect
the pdf backend may have to assumme DevIL to get the format-specific data.
Something like:
cairo_image_pattern_create("filename");
cairo_image_pattern_create(const char* data, int length); // mmap
cairo_image_pattern_create(readf, seekf, closef); // io callbacks
cairo_image_pattern_DevIL_id(image_pattern_t) // returns the DevIL id or
whatever.
Andrew McRae wrote:
>> There are already a pile of pretty good image loading libraries (DevIL
>> comes to mind) that will happily load into a cairo_image_surface_t -- if
>> you think there's a need for yet another image loading library that's
>> specifically tied to cairo, I'd say go for it, but please keep it out of
>> cairo proper.
More information about the cairo
mailing list