Andreas Beck wrote:
>
> Hi Stefan,
>
> > > - 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.
>
> > I don't understand the taskswitch problem. Could you please elaborate ?
>
> The point is, that you will use the shm in the parent to display the
> _current_ contents of the child at some random point. Not at a point the
> child has told you to, or is ready to, like while the child is in
> ggiFlush() ...
>
> That is, you will frequently see half-done drawings on the child visual
>
> The "right" solution would be to stall in ggiFlush() until the parent has
> signaled to proceed. This would guarantee that the parent only displays
> "finished" versions of the childs visual.
I'd propose a simple semaphore, or a rwlock. (possibly compile time flag dependent).
I agree that this is necessary. However, it doesn't replace the callback channel.
Else you would reqire the client to reserve a whole thread just to sit and watch
the visual (literally so :)
I suggest to have both, a semaphore for correct concurrency management, as well
as a pipe/unix socket for callback.
Alternatively, you could use a condition variable, and require the client to spawn
a thread per shm visual.
> >From a dependency point-of-view, I'd then like to go with a named pipe.
> An open() is an open(), you know ... no pipe(), bind(), connect() etc. that
> would add dependencies.
right.
> However it still leves the synchronization problem. Of course we can just
> ignore it, but then again, we don't gain much - only a but of processing
> time by saving unnecessary updates ...
right. See above.
> > 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),
>
> I see. A very good idea for a big number of applications. I suppose you have
> ways to specify stuff like being "pixel-exact" when displaying e.g.
> raster-graphics ?
yes. The PNG format contains a chunk indicating the physical size of the image,
so we can scale. Since berlin is coordinate system independent, all graphics,
rasters inclusively, need to be able to deal with arbitrary trafos. Of course,
if the accumulated trafo is a simple translation, we can use an optimized
drawing command, such as a crossblit. The general case, however, is to do some
mapping.
> > 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.
>
> I see. I have already fixed that for X, given the X server has a correct
> dpi-setting. As said, we'll probably have to configure it for most
> other targets.
Wonderful.
Regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
