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 .)
I wonder if this is problematic or not...
> 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.
> 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).
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 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 :-)).
Rodolphe
