hi,
just a little note to let you know that berlin now can
embedd ggi clients via shm visuals. The event routing isn't
implemented yet but the shm visual already works pretty well.
(The non-trivial part is to not simply blit into the screen
but instead delegate that to the actual DrawingKit which might
use a double buffer...)
The main use of this technique will be
a) allow clients with high bandwidth requirements (video)
to access the drawable (possibly framebuffer in later versions)
directly
b) provide the foundation for emulation libraries (Xlib, gdk, etc.)
for backward compatibility, i.e. to allow X programs to be ported
to berlin.
The next thing to do is to implement event routing. However, as the
client will have a single ggi visual, we still need a region management
library (client side) which figures out the recipient for positional
events. I.e., it will be straight forward to run XGGI as a berlin client,
since X managers do that already (associating events with 'windows').
However, in the long run we don't want to start one XGGI server per client :)
Therefor, we need to factor out (or rewrite) a region manager which provides
that functionality.
Everybody is invited to help !
The 'flying_ggis' running inside berlin looks already very promizing (although
not at full speed since we don't cache (yet) the scene graph in front and behind
the ggi visual, i.e. we need to do a full redraw traversal each time the client
wants to display a new frame. Lots of stuff to work on...
Comments and criticism is highly welcome (though possibly better suited for
one of berlin's mailing list such as berlin-drawing) !
Best regards, Stefan
PS: the setting under which I tested ggi clients was the following:
I use a 'libart DrawingKit', i.e. a renderer implemented with libart,
which renders into a normal ggi memory visual before blitting into the
screen. The shm Drawable is a thin wrapper around a shm memory visual,
which is blitted (at the correct position) into that memory visual by the
DrawingKit.
All that can (of course) run inside X or over /dev/fb.
PPS: as you will notice, this provides a huge potential for optimization simply
by avoiding unnecessary crossblits if possible, and by chosing the 'right'
visual allocation method (heap memory vs. video memory (framebuffer) ).
Therefor any help by experienced 'graphic' people is highly appreciated !
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
