From: BERNARD Sebastien <sebastien.bernard@cegetel.fr>
  To  : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
  Date: Tue, 18 May 1999 10:20:37 +0200

RE: Some though about raster operation.

> -----Message d'origine-----
> De:	Andreas Beck [SMTP:becka@rz.uni-duesseldorf.de]
> Date:	lundi 17 mai 1999 21:51
> À:	ggi-develop@eskimo.com
> Objet:	Re: Some though about raster operation.
> 
> > > No, LibGGI2D is an extension and the reason for extensions is to allow
> 
> > > acceleration of stuff that is beyond the libGGI core.  The core was
> > > kept very basic on purpose, so it could be implemented on the widest
> > > array of display systems and extensions would have something generic
> to
> > > build on.
> > BS]  What is the purpose of the libGGI core ? 
> 
> To be the smallest subset that makes implementing higher primitives
> possible
> at a somewhat decent speed when there is no specialized implementation
> available.
> 
> We drew the line at DrawLine, which is the most complex function in the
> core
> LibGGI.
> 
> > Why then 2 blit function are in the core ? 
> 
> ? You are talking about Copybox and CrossBlit ?
	[BERNARD Sebastien]  Yes, indeed !

> They serve completely different purposes. Copybox is intra-visual, and
> sometimes needed for implementing higher primitives like
> glyph/texture-caching.
	[BERNARD Sebastien]  I repeat that you need logical planes
operations too to be complete. They are basic foundation for sprite
manipulation an so on. Moreover I think that all accelerated 2d engines are
doing these operations (the blitter of the Atari ST was doing it 10 years
-already- ago).

> CrossBlit allows to transfer data between visuals which is included
> to make working with multi-visual setups feasible.
> 
> > I don't understand the underlying logic. 
> > Could someone explain me which operation goes where and why ?
> 
> Everything which isn't in LibGGI yet and does not _have_ to be there
> for some reason (like when it deals with mode/target negotiation or
> similar)
> should not go there.
> 
> Many many apps do not even need the stuff that already is in the core
> LibGGI. The LibGGI core is kind of the lowest common denominator of
> common drawing libs.
> 
> It is totally painless to implement any addition as an extension, so
> we should group every additional set of capabilities that belongs together
> into an extension.
> 
> > 	What I find odd, is that some subroutine are obviously generic (like
> > the one we are talking about) but are considered as specific.
> 
> They are specifically optimized, though the optimization level is
> pretty low. There still is a generic fallback in generic-stubs.
	[BERNARD Sebastien]  Of course, there are. I find the generic stub
is really generic, it copies the image pixel by pixel ! Then, why is there 4
implementation of the puthline in the generic stubs ?

	[BERNARD Sebastien]  Seb		(Scatching his head).