Hi !
> > 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 .)
Oh - yes, I agree, that this imposes quite some unnecessary load. IMHO you'd
be better off by backbuffering as soon as you have more than say 2 or 3
rectangles.
> I wonder if this is problematic or not...
I'd say yes. It is a huge calling overhead, even if clipping is pretty fast.
As long as you use HW-accels, you do each accel call mutiple times, which
wastes a lot of time unless we do batched accel.
> > 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.
Yeah. It might make sense to implement a simple z-buffer operations thingy
or similar for LibGGI3D and base windowing toolkits on that.
Basically that is what they want: Multiple planes stacked on to of each
other, with different depth.
> > 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).
You mean like in filling a figure ? IMHO using clipping to do that is a
braindead idea. They should use fillpoly or tesselate the poly and draw
triangles.
> At least, I know I will need _exactly_ these drawing functions to have
> _all_ the rendering capabilities required for the OpenAmulet GUI library.
Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a
way that makes it more consistent with the other extensions and allowing
to HW-Accelerate much of it.
> implement offscreen windows, and I'll be able to do a dual release of both
> LibGWT (0.0.2 :-) and OpenAmulet (4.3.51 :-)).
GREAT !
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
