From: BERNARD Sebastien <sebastien.bernard@cegetel.fr>
  To  : 'Developement GGI' <ggi-develop@eskimo.com>
  Date: Mon, 17 May 1999 15:51:26 +0200

Some though about raster operation.

IMHO, the ggiCopyBox and ggiCrossBlit are not enough to the high level
application.

There are some raster operation which are missing (some of them are defined
in the svgalib.h).

Say:
	Src is the source
	Dst is the destination
	Msk is a 1-depth bitmap of source'size.

a) a verb which can do Src or/and/not/xor which the dst. This verb will be
possibly implemented using hardware acceleration.
b) a verb which can do dst = (src AND ( dst OR msk) too with hardware
acceleration (if available).


Next, looking at the ggiCopyBox, I see that the implementation is as follow
:
	CLIP(source);
	for line =0 to line = h do
	  copy width*depth  from source to destination

could it be better to do
	CLIP(source);
	start = source;
	end = source + (h* screen->width).
	blocksize = the block.
	if (width == screen->width)
	  witdth = screen->width * h * depth; // Take care about copy of
maximum contigous part of the screen.
	while (start < end) {
	  copy witdth * depth to dst
	  start += width;	// go to the next line.
	}

It is worth ?	This copybox speeds up copy vertical part of the screen
(whole width) from one frame to another.

Could we do some generic subroutine which do basic operations which are the
same from 8 16 24 32 bpp (except for the number of bytes).

Could be done like, generic_ggiCopyBox(*vis, x,y,w,h,nx,ny).
The size of the pixels are already stored in the visual, so maybe could we
retrieve this value from the internal and use it to do our computations ?