> while I'm further investigating the possibilities to
> embedd ggi applications into berlin, I come across a couple
> of (hopefully minor) problems. Here is one:
>
> As the ggi client won't draw into the screen visual directly,
This can be done, but it's pretty scary stuff.
I had thought about allowing such things more generically, but that would
basically require to make LibGGI programs "libraries". This way you could
bind them into the _server_ dynamically, giving them full access to the
main visual - maybe through a subvisual.
> but only into a memory visual, I need a way to let the client
> notify the server, that the memory visual has changed, i.e. that
> the screen needs to be repaired.
I see.
> Does libGGI currently provide any means to achieve this ? A possibility
> for example would be to have kind of a 'expose event' callback, which
> I can register with, say, ggiFlush().
Yes, that would be a good idea. I haven't put any effort into this yet, as
the only example where it made sense up to now was cube3d. And there it
doesn't make much of a difference usually, as you have to redraw everything
at every frame anyway as long as the cube spins.
I think it should be quite possible to add it, as a backchannel already
exists. ggiGetMode can be used to get the remote visuals properties.
That channel could be trivially extended to transfer something like the
"current frame number" (incremented at each Flush). Any good ideas on
where to put this data API-wise ? I'd prefer not to introduce an extra
function just for this single purpose.
Another possibility would be to split the common shm-Eventqueue into two
unidirectional ones and queue expose-events. That would be more precise, as
it can give framed flushes, but also more prone to overflow.
> I'v always wondered how your cube3d example worked. It appears the main
> program only samples the slaves,
Yes - that's the case.
> i.e. there is no synchronization taking place which guarantees a) that
> there is no read access of the visual while the slave is writing
That would require true cooperation between the apps. When the visual
can be read by the master process depends only on scheduling. We could make
proper scheduling more probable by calling schedule() in ggiFlush(), but
that would still not guarantee it. We'd need true locking on that one.
> and b) that the main program redraws after one of the slaves wrote into
> its drawable.
It doesn't. It just runs in a tight loop sampling the slaves. It just has a
"wait-on-input" delay in there, making sure that it doesn't eat 100% CPU and
keeps things moving at the same speed regardless of CPU load.
> Ideas ?
Well - the "correct" thing to do would be to make a Berlin visual driver for
LibGGI. Maybe featuring a very dircet channel (like in MIT_SHM) between the
two. It has the advantage of being able to send acceleration commands down
to Berlin.
That would save all the hassle involved with the shm visual. LibGGI then
behaves like a regular Berlin client. Expose events and all.
> PS: I'm trying to forward events from berlin to the slave ggi program.
That can be done by just using ggiEventSend on the shm-visuals (which must
be opened with "-input" as option). Or, if a true Berlin driver is made it
will be done by the LibGII-driver for Berlin, which again will behave like a
regular Berlin client.
> A fun thing to do would be to run XGGI inside berlin.
Yeah - sure. That's the whole idea of LibGGI. It's kind of "vmware for
graphics display standards" ...
It can be done with the shm-visuals, but a true Berlin driver would probably
be better in the long run. This way Berlin doesn't need special code to
take care of LibGGI programs (though with the shm-visual, you probably
only need a special client for it - right ?)..
> But for this to work I need a way to update the berlin server when the
> XGGI server flushes its visual.
I got some bad news for you in that area: XGGI runs in SYNC mode - that is,
it flushes its contents on a regular basis. This is because the X Consortium
server on which it is based assumes to have a hardware memory area to draw
into.
> Sampling is neither sufficient nor efficient.
However in the case of XGGI it will probably always be the case. Unless
someone goes through all that mess of code and finds every place where
memory gets written to screen and places flushes as appropriate, eventually
caching and combining them to avoid overhead ...
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
