On Tue, 7 Mar 2000, Rodolphe Ortalo wrote:
>
>
> On Sun, 5 Mar 2000, Andreas Beck wrote:
> (as an answer to this question from myself)
> > > Should libggi2d support arbitrary clipping - or would it be acceptable to
> > > have a 'small' version with only rectangular clipping ? (But with decent
> > > drawing functions.)
> >
> > I don't think LibGGI2D should have arbitrary clipping. I'd leave that to
> > a windowing library or a 3D package.
>
> I understand. But I asked this question in the first place because I don't
> feel totally at ease with the way I/we do clipping over regions
> (set-of-non-overlapping-rectangles) in LibGWT.
> I have the feeling of initiating too much workload wrt to graphic context
> switch. (Basically, the way it is done is a loop over all the rectangles
> composing the region while calling set-GC ; draw .)
Ugh. IMHO you should define a function which sets up the clip
regions however you want to represent them, and then have the target code
decompose that into a set-GC ; draw loop, or a stencil mask, or a set of
GL clip planes, or whatever. You will lose all your optimization
potential if you hardcode the clipping algorithm as you describe above.
> I wonder if this is problematic or not...
I think it is.
> > I only know about 2 hardware clipping implementations: 1. single rectangle
> > nad 2. z-buffer or window-id (which is essentially the same except for the
> > comparision function).
> >
> > Thus I think complex clipping shouldn't be handled by LibGGI2D, as it is
> > rarely needed and it would require the hardware to support method 2 to be
> > able to do accelerated drawing (o.k. - we could dynamically switch drawing
> > functions if multiple clips are active, but that would add a lot of
> > complexity without need).
>
> OK. Especially if LibGGI2D is oriented towards hardware acceleration,
> complex clipping should not be too much different from hardware chipsets
> capabilities.
Right, like alpha/z/stencil tests or window IDs |->.
> > I think LibGGI2D would mainly be handy for stuff like making stuff like
> > statistics plots or similar for an existing application. Could be very
> > handy for web based dynamic graphics e.g. These applications don't require
> > complex clipping.
>
> Hmmm. I'm not so sure... It seems to me that vector oriented programs do a
> lot of clipping indeed; e.g. against polygonal region (a filled graphic
> plot).
GL clip planes.
> Well, we'll see. Anyway, I still think that libxmi may be an interesting
> candidate for a GGI sub-lib. It would surely raise problems wrt hardware
> acceleration - so not for LibGGI2D in the first place - but it may be nice
> to have a decent set of drawing functions. (libxmi is a legacy extracted
> from the public X11 sources - it is used in gnuplot according to the
> documentation. It provides all the usual drawing functions of X11 - but it
> is a software oriented rendering package in the first place [maybe even in
> the design itself]).
I actually think this is a much better idea than LibGGI2D itself.
LibXMI has a specific purpose and welldefined boundaries to its design,
whereas LibGGI2D's design is much more generic and ill-defined. Thus, it
should be easy to turn LibXMI into a LibGGI extension and accelerate its
operations in the appropriate target code, and we'd always know where we
stood and what functionality to support. Contrast this with LibGGI2D,
where we cannot agree even on what functionality should be present in the
library API itself, to say nothing of how to accelerate it! I think that
says a lot.
> I don't know these issues much. I'd like to have additional advice from
> people knowing GGI.
> At least, I know I will need _exactly_ these drawing functions to have
> _all_ the rendering capabilities required for the OpenAmulet GUI library.
> And this will hopefully be very soon: I mainly need to understand why
> libgwt's evExpose events gets messed by OpenAmulet currently, and to
> implement offscreen windows, and I'll be able to do a dual release of both
> LibGWT (0.0.2 :-) and OpenAmulet (4.3.51 :-)).
Sounds good!
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
