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.
> > "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 ?
Yeah - something like it. We will probably just be able to use the ggLock/
Unlock prmitives, though there might be a sick architecture where it
wouldn't work over shm ...
> Using a fifo would allow us to use a reactive model...
I see. Your points about select() below also apply ...
> I think SYSV messages are highly discouraged in the unix community. They
> don't fit well with select and family.
Yes. I see.
>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.
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 ...
> 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 ?
> 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.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
