Index:
[thread]
[date]
[subject]
[author]
From: Brian S. Julin <bri@tull.umassp.edu>
To : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
Date: Tue, 18 May 1999 12:35:16 -0400 (EDT)
RE: Some though about raster operation.
On Tue, 18 May 1999, BERNARD Sebastien wrote:
> [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 ?
To clear things up, there is only one PutHLine in the "generic stubs".
There is also puthline_nc, which is a trusting version that does not
clip the coordinates.
I'm assuming "default renderers" are what you are referring to/complaining
about, and there are many more than 4 of those, each with their own PutHline.
This is all done for speed.
The way the generic stubs and the default renderers work, they are set
up to use better, faster routines at any point. Suppose you had an
accelerated driver library that implements an accelerated PutHLine,
but does not implement an accelerated PutBox. If you call PutBox,
it goes to the generic stubs function, which tries to draw the box with
PutHLine, which then goes and uses the accelerated PutHLine.
If they didn't implement _all_ the primitives, the generic stubs
would consider the depth-optimized functions in the default renderer
to be faster and better and use them instead. They are, after all.
Since they implement all the primitives, the generic stubs are never
touched at all. This system has the nice quality that if suddenly you
wanted to draw on some strange surface like a 7-bpp, 6-bit-chunk-packed,
5-line-planar, reversed-endian buffer, but don't necessarily want to write a
whole renderer you can implement just PutPixel for this format and it
will work, albeit slowly.
Extensions do not cost a lot to load; it simply boils down to what you want
is LibGGI2D (or some other library, say LibGGIBLT), not LibGGI. LibGGI
is for writing programs top-down and for porting programs that were written
top-down on using nothing but a basic framebuffer and which implemented
all the special operations they needed themselves. Anything that mixes/ports
more advanced structures and operations really needs an extension. Sorry
that your extension hasn't been written yet, but there are a whole lot of
things being written around here and not enough people doing the writing.
Even if we decided to put it in LibGGI, that wouldn't make it get written
any faster.
--
Brian
Index:
[thread]
[date]
[subject]
[author]