Subject: Re: Image handling [draft]
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Fri Apr 20 2001 - 10:53:29 CDT
>Dom, I'm willing to listen to you too.
Ok, please consider the following (because I'm feeling compelled to
implement it) and consider it a good compromise:
This involves: us having 1 or 2 ifdefs for HAVE_GNOME or you favorite XXX
platform library.
In the special case of Gnome or some specialized *native* imaging solution,
we'll want to take advantage of the functions available to us. We'd do the
following:
1) We create a newer, more robust imaging API. PNG and SVG are still
"sort-of" our native formats. By this I mean that we no longer have things
like UT_PNG_GetDimensions() or UT_SVG_GetDimensions in our XP code, but
rather we have something like:
ImageClass->getDimensions();
where ImageClass just happens to be wrapping a PNG or SVG image. It's fine
to use the UT_XXX_GetDimension calls inside these classes/subclasses only.
We need to do this (#1) regardless of HAVE_GNOME anyway.
2) Replace the proposed IE_ImpGraphic with IE_ImpGdkPixbufGraphic or
somesuch beast
2.a) This allows us to do native loading of a potentially huge number of
image types via a common (and simple) API
3) We can use that aforementioned library to also render the pixbuf to
screen/printer, etc...
4) We only support PNG and SVG in the ABW format (and possibly JPEG as well,
but I'm not wholly convinced on that matter).
4.a) We get inter-operability between the different platforms, at least at
render time, which is what matters
4.b) For my GdkPixbuf class I do one of:
4.b.1) gdk_pixbuf_save() and serialize the pixbuf as a PNG (only for
gdkpixbuf versions >= 1.0 though)
4.b.2) Extract the RGBA data from the pixbuf, and use libpng to serialize
the data back into PNG form for storage on-disk
4.b.3) Some other way. This is an implementation detail that I'm more than
happy to take care of/worry about myself.
Pros:
People on win32 can render my images, people on GNOME can load 50 image
types instead of just 3, I can do it faster and with < RAM, and the file
format doesn't change. We also present a common API/Interface in both cases,
so it's "all good" as far as XP code goes.
Cons:
A few ifdefs and Makefiles that I'm willing to maintain
Does this sound reasonable?
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Fri Apr 20 2001 - 10:53:33 CDT