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]