Subject: Re: More on imaging
From: Paul Rohr (paul@abisource.com)
Date: Fri Apr 27 2001 - 20:44:04 CDT
As of this last grand mal post, I think I've batted all the imaging balls
back out of my court. If I've missed anything relevant, please let me know.
At 10:09 AM 4/26/01 -0400, Leonard Rosenthol wrote:
>>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.
Bingo. I haven't looked either. I'm hoping that if this *is* a good idea,
then Paolo or someone else could step in and educate us.
>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.
Agreed, but in the scope of things this should be quite minor. For example,
all of our platform implementations make C calls to the underlying platform
APIs. Once we know what functionality we want, expressing the API to that
glue layer in C++ shouldn't be controversial.
>>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?
Exactly. These are excellent questions, and the various proposals being
floated have sometimes been fuzzy here.
I'll get the ball rolling by asserting that the only API I ever cared about
-- the switching mechanism to invoke this whole mess (from importers,
clipboard, etc.) -- should definitely be XP.
Because I'm feeling frisky, I'll also go a step further and attempt to
summarize what I understand of everyone else's position. That's usually a
great way to provoke any needed corrections. :-)
From 10,000 feet I suppose you could divide the current proposals along two
roughly orthogonal axes:
- native vs. XP (for file formats, at least)
- PNG vs. RGBA
If so, that'd produce four [*] permutations as follows:
1. native, RGBA ... (Dom) Unix-only gdk-pixbuf to RGBA to screen
2. native, PNG ... (Thomas) BeOS/QNX native to PNG to GR_Image
3. XP, PNG ... (Hub) libjpeg, etc. to PNG to GR_Image
4a. XP, RGBA ... (anyone?) XP gdk-pixbuf to RGBA to GR_Image
4b. XP, RGBA ... (Leonard) ImageMagick to RGBA to screen
I've already sent a number of messages mapping out the code paths for most,
if not all, of these. Also, by now it should be clear which sections of the
code path are XP. However, I'd be happy to send more ASCII art if needed.
If you envision the import / conversion / export / display process running
from left to right, we can make the following observations:
1. could easily be native throughpout
2. native on the left, XP middle, native on the right (display)
3. XP left and middle, native on the right (display)
4a. XP left and middle, native on the right (display)
4b. XP throughout ?? (depends on what the display APIs are)
We do seem to be clear on the following:
- we'd like to keep the codepath as short & fast as possible
- we should minimize the number of image buffers in the chain
- nobody wants to write any more code than they have to
Most importantly:
- the PNG vs. RGBA is a *key* open issue (see separate thread)
If we decide that we want to carry PNGs in memory, then the proposals morph
into:
1. native, PNG ... (Dom) Unix-only gdk-pixbuf to PNG to GR_Image
2. native, PNG ... (Thomas) BeOS/QNX native to PNG to GR_Image
3. XP, PNG ... (Hub) libjpeg, etc. to PNG to GR_Image
4a. XP, PNG ... (anyone?) XP gdk-pixbuf to PNG to GR_Image
4b. XP, PNG ... (Leonard) ImageMagick to PNG to GR_Image
Since the right half of the picture (PNG to GR_Image) already Just Works,
the key remaining issue(s) would be:
- performance vs. power to the left of PNG
- choosing 3 vs. 4a vs. 4b for XP
- settling on a PNG-centric API usable by 1, 2, and something XP
By contrast, if we agree that we want to carry RGBA and not PNG in memory,
the proposals morph into:
1. native, RGBA ... (Dom) Unix-only gdk-pixbuf to RGBA to screen
2. native, RGBA ... (Thomas) BeOS/QNX native to RGBA to GR_Image
3. XP, RGBA ... (Hub) libjpeg, etc. to RGBA to GR_Image
4a. XP, RGBA ... (anyone?) XP gdk-pixbuf to RGBA to GR_Image
4b. XP, RGBA ... (Leonard) ImageMagick to RGBA to screen
If so, then the relevant issues become:
- performance vs. power to the left of RGBA
- how to minimize the amount of platform work from RGBA to screen
- choosing 3 vs. 4a vs. 4b for XP
- settling on an RGBA-centric API usable by 1, 2, and something XP
OK, now that I've probably subtly mischaracterized everyone's positions, let
the fur fly! :-)
Paul
motto -- explicitness for the sake of good design is no vice
[*] Four permutations, with two alternatives in the fourth category. In
other words, 4 ==> 5 because I wrote the whole message with four examples
and then went back to add one more when I was done. :-)
This archive was generated by hypermail 2b25 : Fri Apr 27 2001 - 20:36:46 CDT