Index: [thread] [date] [subject] [author]
  From: Brian S. Julin <bri@tull.umassp.edu>
  To  : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
  Date: Mon, 17 May 1999 12:24:43 -0400 (EDT)

RE: Some though about raster operation.

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

------_=_NextPart_001_01BEA079.86FBC580
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-ID: <Pine.LNX.3.96.990517120332.732D@tull.umassp.edu>

On Mon, 17 May 1999, BERNARD Sebastien wrote:
> 	[BERNARD Sebastien]  Is libggi2d using lowlevel acceleration ? For
> me it is not  clear which operator goes to which library. The stubs for the
> BlitOp are empty.

LibGGI2D is still very young and incomplete.

> IMHO all the operations that can be accelerated could be
> in the libggi, and only really high level operation must be in the libggi2d.

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.

> > > 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).
> > 
> > That is pretty much what the generic stubs do.
> 	[BERNARD Sebastien]  No, look at GGI_lin{8,16,24,32}_copybox in the
> copybox.c (default/linear_x directory). This is pretty the same  but for one
> constant. Why not using one subroutine instead of 4. 

Because:

> The value of the constant could be deduced from the visual (so the routine 
> is not realy specific to the display).

...and deducing it from the visual every time you call a drawing operation
wastes CPU cycles both from the very act of doing it and from the effect
on compiler optimization.  Plus having the renderers as a back end allows easy 
solutions to endian/plane-layout problems by loading a properly chosen 
optimal function for that bit depth.  Note that the subroutines are loaded
dynamically, so if you aren't using them, all they do is take up disk space,
and if you never intend to use them you can delete them and remove them
from the config files.

(There are preliminary plans for better BLT buffer management in the works.)

--
Brian

------_=_NextPart_001_01BEA079.86FBC580--

Index: [thread] [date] [subject] [author]