From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 May 1999 00:59:55 +0200

Re: Some though about raster operation.

> > They serve completely different purposes. Copybox is intra-visual, and
> > sometimes needed for implementing higher primitives like
> > glyph/texture-caching.
> BS]  I repeat that you need logical planes
> operations too to be complete. 

No. They can all be emulated by a GetPixel;DoLogOp;PutPixel system.

I know, that this is slow, but you have plenty of room to optimize even
if you want to go through LibGGI (instead of bypassing it in the extension
if you know a better way).

A very common way to do it on non-accelerated targets would be to
read/modify the image in a directbuffer, or if you have none, getbox
the background, fold it with the sprite and then putbox it.

> 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).

Yes. What makes no point against just making it an extension.

> > 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 ?

This is not due to a property of the image but rather due to one of the
packed pixelbuffers used. It's probably the best thing to do to avoid
having a really ugly bunch of code caring about endianness issues,
unaligned access and similar.

CU, Andy

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