Index: [thread] [date] [subject] [author]
  From: BERNARD Sebastien <sebastien.bernard@cegetel.fr>
  To  : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
  Date: Mon, 17 May 1999 18:25:14 +0200

RE: Some though about raster operation.

> -----Message d'origine-----
> De:	Brian S. Julin [SMTP:bri@tull.umassp.edu]
> Date:	lundi 17 mai 1999 18:25
> À:	'ggi-develop@eskimo.com'
> Objet:	RE: Some though about raster operation.
> 
> 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.
	[BERNARD Sebastien]  What is the purpose of the libGGI core ? Why
then 2 blit function are in the core ? I don't understand the underlying
logic. Could someone explain me which operation goes where and why ?

> > > > 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.
	[BERNARD Sebastien]  I completely agree with you about separation
and specific profiling of targets.
	What I find odd, is that some subroutine are obviously generic (like
the one we are talking about) but are considered as specific.

> (There are preliminary plans for better BLT buffer management in the
> works.)
	[BERNARD Sebastien]  Don't know about it. Tell me more.

> --
> Brian

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