Hi !
> > I think that is the best compromise between speed (single pixels would use
> > less memory, but it would crawl) and memory usage.
>
> Well, I don't like compromises when you can get both worlds. ;)
> What I want (for the simple conversions like truecolor<->truecolor
> at least) is:
Ouch - we were talking about very different stuff :-).
> convert(handle1, handle2);
> which doesn't do any intermediate load stores.
Sure. I intended to handle that case by a chain of callbacks that will massage
the incoming data into the intended outgoing format. That can be done in place
in many cases.
> But maybe we're talking about different things? I'm just talking
> about conversions from one pixel-format to another.
Yeah, and I'm with you on that one.
> If you're talking about reading an image file from disk and writing it out
> in another image format you will ofcourse need some intermediate buffer.
O.K., yes, that was what I was talking about - so we agree ... nice.
> > Regarding LibGFP I can send you a draft for the external API that was made
> > up by me and C.Egger in the meantime. Interested ?
> Sure, send it over.
O.K. - I'll send it along together with a new design study for LibGBL (GGI
BLitting) and LibBSE (now a wrapper around GBL and the yet-to-be-written
LibOVL).
For GBL and OVL to work nicely, we will need some way of allocating offscreen
video memory. Any ideas on that ? Should that go into LibGGI or should we push
it into an extension ?
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
