Christoph Egger writes:
>
> On Tue, 14 Aug 2001, Eric Faurot wrote:
>
> > Hi all,
> >
> > Looking at libgpf, I noticed a few problems with the current
> > highlevel API :
> >
> > - It doesn't handle palette formats.
>
> It doesn't do that as the result (the picture) is stored in a visual.
huh? I thought it was not bound to ggi at all.
> > - We can't initialize a image to write with a given size/frame
> > number.
>
> gpfSelectImage() is for multiimage formats like gif. You can say I wanna
> read the third frame of it. gpf handles a picture as a kind of streaming
> data. The size is handled in lowlevel.
But If I want to write a 4-image gif, how do I tell the driver?
> > - Writer and loader drivers must be separated to decrease
> > the memory footprint on embedded systems, especially when
> > encoding is complicated. ( maybe it was thought like this )
>
> This is done in the lowlevel API.
>
> > - The read/write callback should accept another void * argument
> > to 'contextualize' the call. (I hate those context-less SAX
> > parsers!)
>
> See lowlevel API.
Well, it's not really obvious...
I don't understand then how the highlevel API is supposed to be used.
Is the code in CVS up-to-date ?
> I wrote libgcp to handle that. It still doesn't handle everything,
> what is needed for libgpf.
I wonder if this could not take advantage of the batchop idea to
transform between pixel layout.
> > */
> > int
> > gpfRead(gpf_handle_t handle, gpf_pixelformat_t format,
> > gpfReadCallback cbR,
> > gpfIndicatorCallback cbI,
> > void * data);
>
> Not needed. This is handled by the driver internally. The driver converts
> data into a rgb data stream.
This is ok as a default behaviour, but what if you want to get another
layout? say, to feed a framebuffer.
I thought of libgpf as generic way to get raster stream, not a
especially for loading an image in a visual (it's trivial though)
> Read the libgpf/doc/EN_design file. The way of handling is explained
> there.
I did. I'll go through it again though.
Eric.
