From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Sun, 30 May 1999 23:56:46 +0200

Re: BlitOp Implementation

> libggi2d/default/stubs/blit.c looks to be place to implement
> BlitOp and friends.  As this would be the lowest common
> denominator fallback code, I assume it should just use
> GetPixel and PutPixel to do its thing.

Yes. The stubs stuff always uses fallback functions, and Get/PutPixel
seems like the way to go for that purpose.

> However, I am interested in using direct buffer access to get
> as much speed as possible.  I've already written the following
> function:

> void dbFastBlit( ggi_directbuffer *src, int sx, int sy, int sw,
>                  int sh, ggi_directbuffer *dst, int dx, int dy )

> This is a quick and dirty function that operates on two direct
> buffers and copies a rectangle from one to the other.  It
> assumes that the color palettes etc are the same for both
> visuals.  When both visuals are in video ram, this is very
> fast (MUCH more so than when the pixel is temporarily buffered
> while being copied).  It should be trivial to modify this
> to check the alpha value when copying... bingo, I've got
> transparent blitting.  This is fine for getting my game
> engine up and running, but I would also like to give something
> back to the GGI project.
> 
> My question is, what is the proper home for this code in GGI?

It is in the linear_* libraries, where you can even optimize further,
as you have a few a-priori assumptions about the visual.

> My gut tells me it should NOT go in the default BlitOp stub.

LibGGI (and all extensions) works as follows:

When setting a mode, the LibGGI code visual driver code determines a set 
of "rendering-APIs" which are designated by a set of "suggest-strings".

Then the LibGGI code loads rendering libraries as the strings suggest.
This also affects extensions, which do the same.
It always starts with "generic-stubs" and then continues with more advanced
libs. If some of them fail to load, this is no problem - it's just that the
optimizations done there won't kick in.

For LibGGI2D this means, that you just write optimized versions of the
blitting code in each of the linear_* subdirectories.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =