>What I was asking was whether anyone (such as Paolo) thinks that gdk-pixbuf
>(or something like it) can or should be used on *other* platforms as a
>lighter-weight alternative to miniIM as our XP API.
Theoretically, yes. The big limiting factor is the need to bring
along some (potentially large?) chunk of gkd & glib with it. I haven't
looked to see how much we'd need to carry beyond what we already
do. Another issue (though not a big one) is that gdk-pixbuf uses a C API
and we're a C++ "shop", so we'd want/need to wrap it in one or more classes.
>Thus, my attempts to clarify what we're all talking about so we can make an
>informed decision and move forward. AFAIK, we have consensus that any XP
>API should support both of the following:
>
> - platform-specific implementations to leverage system services
> - one or more XP implementations
The problem is that you also need to break down the areas of
"image handling" as well to determine what is XP, what is platform,
etc. Consider:
* Raster file format handling (JPEG, PNG, etc.)
* Vector file format handling (SVG, WMF, etc.)
* Conversion of vector format to RGBA buffer (ie. a rasterizer!)
* RGBA buffer tracking
* Image manipulation (scaling, etc.)
* Blitting buffer to platform "window"
Which ones should be XP and which shouldn't? Which should have
"hooks" for platform-specific features and which shouldn't? Do we want a
single API/library that can handle all of the above or should we be looking
at multiple solutions? If multiple, do they need to be compatible with
each other?
LDR
