On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote:
> > (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.
Backbuffering is one possible solution. But I guess also that I could
also reorder LibGWT internal drawing calls to minimize the GC-switches.
> 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.
Yes but... it's simple and does not require Z-buffer management (which
realistically should be done primarily in hardware). Well, anyway, as you
have surely understood, my principal concerns with LibGWT currently are
not performance-related. I'd like to have it running with full
functionality first! :-) [I lost nearly 6 months scratching my head in
front of event dispatching... The solution was too simple.;-)]
> 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.
Yes, it may make sense. And this is probably what Berlin requires. LibGWT
has a more narrow ambition...
> > 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.
Mmm... Yes, surely. Well, the most convenient way is probably to direct
you at the documentation of OpenAmulet on the Web. It is accessible via a
link on the http://www.openip.org/ web page. Inside the full
documentation, the layer that wraps the OS's graphical library is
described in the 'GEM' chapter.
Basically, this layer is a subset of the X11 drawing functions. You need
'styles' (for lines and for filling). The drawing methods of a GEM
object (OpenAmulet is in C++) are:
Draw_Arc, Draw_Image (ie a pixmap), Draw_Line, Draw_Lines, Draw_2_Lines,
Draw_3_Lines, Draw_Rectangle, Draw_Roundtangle (a useful singularity) and
Draw_Text (w/ complex fonts, this: later!).
Looking more closely, you'll also see that a Bitblt method is needed
(but this one is already available in LibGGI itself).
As you can see, this API is pretty simple - and corresponds closely to
what you can find in libxmi (or X11). Hence my suggestion to use already
available software implementations like LibXMI (over LibGGI directbuffer).
Of course, a similar API with hardware acceleration would be wonderful.
But maybe this time would be better spent over LibGGI3D (where 2D would
only be a specific case).
I'd tend to give higher priority to a 2D API personnally, but I am partial
on this (I need it :-). Berlin's people would surely have opposite
priorities (and a much higher need for hardware accels).
Maybe we need both in fact.
Rodolphe
