On Tue, 7 Mar 2000 [EMAIL PROTECTED] wrote:
> Hi !
>
> > GGI - as far as I know - has only a notion of a rectangular clipping
> > rectangle being valid for all subsequent primitive drawing calls.
>
> Yes. This is due to the fact, that there are only two methods I have seen to
> do clipping in Hardware:
>
> 1. a single rectangle (eventually invertible, i.e. you can only draw _outside_)
> 2. a Z-Buffer, stencil-buffer or windowID-buffer. That is with 2. you can
> decide for every pixel, if it can be drawn to or not.
3. Alpha/Colorkey/transparency. You can decide for every pixel, but based
on pixel value, not coordinates.
> > Well, what, if I have a clipping region, like X does, which I can
> > subdivide into an enumeration/array of rectangles?
>
> I would try to use 2. (which is more in the scope of LibGGI3D than plain
> LibGGI) or emulating that.
You should define functions to establish clipping settings,
however they may be defined, and let the target code decide how to
accelerate the clipping operations. Do not try to do this optimization
explicitly or it will be very messy and very difficult to optimize for the
target environments.
> > Do I have to repeat a single e.g. line drawing call,
>
> I cannot recommend that, unless you have a very very powerful accelerator and
> a very very weak CPU or are low on RAM.
>
> If not, I'd draw the window (which is what you are hinting at - right ?) into
> RAM and then blit over only the visible portion, which can be done by just
> crossblitting the clipping rectangles.
>
> This also provides backbuffering, which is usually a nice thing to have anyway,
> as you can redraw contents without application help, which is useful for stuff
> like opaque window moves.
We need a viewport-management extension....
> > after having reset the clipping rectangle each time or is there a
> > (maybe private, but stable) function / shortcut??
>
> No. As said, LibGGI3D should have such functions as Method 2. falls into its
> scope, but unfortunately LibGGI3D is not in a useable state right now AFAIK.
Nope, and as I mentioned in another mail LibGGI3D will not remove
the need for procedural APIs to driver the target environments. It will
just make it a lot easier to bind the functionality of these procedural
APIs into abstract rendering streams and contextual units.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
