Eric G. Miller wrote:
> currently Glynn and me are hunting a KDE/Xdriver problem related to the new
> auto-redraw feature of Xdriver. Perhaps someone here has a hint for us...
>
> If displaying a raster map and one or more vector maps, now resize the GRASS
> monitor with a mouse, sometimes the vector maps disappear (so auto-redraw
> doesn't work properly). The raster map is mostly there. This only appears on
> KDE while Xdriver runs well on GNOME windows manager.
> Difference between KDE and GNOME:
> - KDE immediately redraws window contents when resizing
> - GNOME waits until the mouse button is released (only shows
> a moving frame without contents, then redraws contents after
> window got settled)
>
> The KDE way leads to problems. Adding a sleep(1) before redrawing helps
> a bit but isn't perfect. Any other ideas? Could we catch the
> mouse-button-release event and then redraw?
>
> And: The problem only seems to appear, when resizing, while the redraw
> is ongoing (means: two resizes quickly following each other). Perhaps
> the redraw order is confused: vector first, then raster which would make
> the vectors invisible?
I don't remember if I committed some changes I was working on regarding
processing Xevents, but the scenario is like:
If the window manager uses a rubber-band box for moving/resizing
windows, then it only generates one Expose event. If the window manager
uses opaque moving/resizing it is likely to queue up a whole bunch of
Expose events. Ahh, I see that should be handled...
Do you mean ConfigureNotify?
Now, on the pad thing, what I see is at the end of handleResizeEvent()
there are two forks() and one waitpid(). Inside the inner fork is a
loop that shells out the items from PAD. So, if I'm understanding
correctly, the second fork() returns in the parent which then does
exit(0) whereby the waitpid() returns and the function finishes.
Actually, it's the short-lived child of the first fork() that is
reaped by waitpid; the parent process has to get back to event
processing otherwise you get deadlock.
The
inner forked process is meanwhile trying to shell out the PAD items, but
if another resize event comes in while the shelled commands are pending,
then a second go around of this occurs. However in the second go
around, some pad items never get redrawn (and hence added to the PAD
again). If you add a third resize while the second is running, you
really start to lose pad items. I just tested this and indeed I lose
the vector if I do three resizes (where there's one large raster and one
vector originally). So we have a race going on (go speed racer!).
I'm pretty sure that this is it; resize events won't be handled while
a client is connected, but they will be handled between clients.
I don't see any easy solution. Maybe that's why someone way back when
decided a resize event would clear the screen and the pad contents...
Hmm, what if there was a way to handle the resize without deleting the
pad contents? I don't know if this would work (probably not): In
theory, when a drawing command is shelled out on the resize, a new pad
item should be added that is identical to the old pad item. So, what if
adding a pad item first checked if it matched an existing item. If so,
it just increments a counter for that item. Periodically (say, in
do_events()) we look at the pad list to see if all of the counts are the
same. If they aren't, then some commands were lost and need to be
recreated. Hmm, no I guess you'd never lose commands in that
scenario. They'd just end up drawn all weird and the server would never
know.
Hmm, maybe having a "saved" pad and a "current" pad? I'll stop now 
I think that XDRIVER will have to do proper process management. The
existing code is really just proof-of-concept.
The first draft only did a single fork(), which left the child
processes as zombies. The double-fork was a quick hack to get around
this (now, by the time the grandchild dies, its parent is long gone,
so it will get reaped by init).
This is the "fire-and-forget" approach, but it clearly isn't going to
work. The main process needs to keep track of the processes which are
spawned for redraw, and not spawn a new process while a previous
process is still active.
Also, it would ideally only accept connections from the redraw
commands whilst a redraw operation was in progress. However, this
would require the platform to support getsockopt(SO_PEERCRED).
Otherwise, there would be problems if a user resized the window whilst
running a script containing GRASS display commands.
--
Glynn Clements <glynn.clements@virgin.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'