Andreas Beck wrote:
> > * visual update feedback (through named pipe or unix socket)
>
> > add a fifo to the shm visual structure, and implement the ggiFlush
> > functions such that the repaired region is reported back through the
> > channel, if desired.
> > The initializer string could simply be completed by a token "-p:<name>"
> > or "-s:<unix sockaddr>" indicating whether the client wants feedback
> > and if so, what transport.
> > If nobody else is working on that one, I'm probably putting my hands on
> > it myself shortly. This would be essential if we want to provide a low
> > level emulator for porting X applications to berlin.
>
> O.K. - please reconsider this one closely, if you really think it is a
> good idea. Doing so would induce a bunch of possible problems:
> - stalling the attached application when the pipe gets full
> - handling of signals
> - many apps are pretty dumb about updates and flush often or are SYNC. You
> would need to pre-optimize drawing from multiple entries in the pipe
> in many cases.
> - it doesn't solve the locking problem - i.e. you can have a "half baked"
> picture in the shmvisual, as taskswitching may occur at any time.
> - it adds an extra dependency to the underlying OS.
hmm, you raise a couple of good points. If an application starts a ggi
client and explicitely asks for a socket/pipe for 'callbacks', I'd assume
it is his responsibility to read the data out. In fact, what I propose is a
synchronization point. It is really for situations where the ggi application
draws into shm as part of a pipeline. In this context, there is no point in
not synchronizing both sides. Of course, the flags '-s' and '-p' are optional,
i.e. you still can run applications the way you currently do.
If applications flush unnecessary parts of the visual, that's their fault.
They should not, and I don't see why we shouldn't use ggiFlush/ggiFlushRegion
to our advantage just because it is abused. It should be trivial to repair
such an abuse, in case it really matters. (In fact, I hope that the GGI embedding
in berlin feature will attract people to port stuff to ggi (gdk for example)
to be easily ported to berlin, so they might as well do it right from the beginning).
I don't understand the taskswitch problem. Could you please elaborate ?
> I will think about an alternative in the meantime. I'm considering something
> that goes inband through the shm area, just like the events do.
> I am thinking along the lines of a struct that gets updated with a
> "changed region rectangle" and that has a spinlock that gets released in
> ggiFlush() only. That would allow to run the parent only while ggiFlush()
> is active.
possible. You are thinking of semaphores, right ? Well, that would mean we'd need
an extra thread for it. Using a fifo would allow us to use a reactive model...
> I got to look into SYSV-IPC message queues as well - maybe one can use them.
> The idea there is, to at least avoid the extra dependency. If we have SYSV-
> SHM we very probably also have the messages ...
I think SYSV messages are highly discouraged in the unix community. They don't fit
well with select and family.
> > * physical size of a visual
>
> > as I once proposed, it might be desirable to know the visual's physical
> > dimensions. Lots of applications need such information, so it would be
> > best to provide that info at a low level instead of requiring every
> > application to provide a calibration tool. Some devices provide that
> > information, in which case you could simply use that to fill in the
> > visual.size part. Else provide some means to read that information from
> > a central configuration file (probably together with other necessary
> > data
>
> Yes. 120% agreed.
>
> > This requires some thought / design, so I'm not going to do anything
> > without your suggestions / feedback.
>
> O.K. - what do you need to know ?
our ultimate goal is 'resolution independence'. Before we were all brainwashed,
setting the resolution meant to specify how many pixels fit in a given physical
length. The size of graphical objects was *not* touched.
In berlin, we specify graphical object sizes in physical units (mm for example),
and let the DrawingKit (the renderer) figure out what that means in terms of
pixels. The DrawingKit therefor needs to know either the resolution or the physical
size of a pixel. This is currently not possible without manual intervention, as
the visual's size isn't set. If it was set, and would indeed represent the physical
dimensions of the visual, we'd know the resolution immediately. Of course, this
matters most if a visual represents the whole screen (as it does usually in berlin).
We have for example another DrawingKit for printing (a 'PSDrawingKit'). It will
know (through configuration) what the resolution of the printer is, and then adapt
to print the scene in the exact same size as it would appear with the screen
DrawingKit.
WYSIWYG at its best.
Best regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
