From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 22:04:02 -0700 (PDT)

Re: Can I do that ?

On Fri, 21 Aug 1998, Olivier Galibert wrote:

> With GGI, and existing extensions if needed, can I:
> - open a 256x256x(3b  per color) screen (having  to go to 15/16/24bits
>   is of course acceptable :-)

	I think the 3bpp will work, at least with an abstract memory
visual.  LibGGI folks, do we have a construction-based color layout scheme
yet?  I heard people working on it but I had my head buried in kgicon at
that point....

> - create four 272x272x(9+) pixel buffers

	Just create some more memory visuals with whatever properties you
wish them to have. 

> - every  vbl  update part  of the   buffers by   copying in them  some
>   rectangular pictures in main memory.  These pictures' depth is 7bits
>   and require a color table lookup for each pixel.

	Sure, if your target supports WaitRayPos() for vblank
synchronization.  AFAIK only the SVGALib target does right now.  I could
add it to the Glide target, but it would require polling (how does the
SVGALib target do it?)

	Anyway.  About the 7bit CLUT -> 9+ bit whatever copying, sure you
could do it.  If you want colorspace translation, write a target to do
whatever you need and render from the main memory to the memory buffers
through that translation-target.  Look at the existing trueemu and palemu
targets to see examples of how this could be done.

> - every vbl copy each pbuffer in the display buffer with transparency.
>   Some   transferts will be  done in  4 rectangular  parts to simulate
>   panning.  Of course, double-buffering has to be used.

	Sure, with the caveat that if you try to do too much stuff in
software during the vblank the next frame will start before your code is
finished and you'll either have to wait until the next vblank to update
the display or risk tearing artifacts.

	As far as the transparency goes, either draw through an alpha
stencil or use a custom transparency target.  And the double-buffering can
be done by rendering to an offscreen visual and flushing it to the display
visual (which would probably be a DirectBuffer mapped to the hardware
framebuffer) every vblank. 

> If the hardware if appropriate, all of  this should be done within the
> card, of course.  Otherwise the libggi* will have to emulate all these
> in main memory, the fastest possible of course[1].

	Of course.  Now, you have to realize that "the fastest possible" 
requires more and more code, specialized targets, KGI drivers, etc to get
closer to.  But in priciple you should be able to optimize the rendering
pipeline as finely as you have the time and inclination to do.  With
LibGGI, all is possible.
 
> Can one do that?  If no, what is missing?

	The code to do those specialized, nonstandard colorspace
conversions and good vblank handling in LibGGI targets is what is mostly
missing.  But as far as the LibGGI framework is concerned, I can see
nothing missing at all.

>   OG.
> 
> PS: I  hope you have gone  away from this "the user  has to change the
> base y for double-buffering" thingy, eh?

	Of course.  "Double Buffering" means having two buffers, one of
which is drawn into and one of which is displayed.  How those two buffers
are laid out in memory, how their updates are sychronized, etc. - those
are implementation issues.

> [1] Which should be almost as fast as a specialized implementation for
> the  application, and maybe even faster  because this can be tuned for
> the target hardware.

	Precisely.  You can optimize the rendering path between the
application and the final display target as much as you want.  The
ultimate expression of this would be one huge target that was specifically
for rendering from one particular application to one particular display
target in one particular way.  You *could* encapsulate the scheme you
described above in one huge, custom-built display target if you were a
masochist.  But since most of the tools you wanted are already available,
it makes more sense to piece your solution together out of the existing
LibGGI components and only create what doesn't already exist.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed