[GRASS5] hunting KDE/Xdriver redraw problem

Eric G. Miller egm2 at jps.net
Wed May 16 01:11:57 EDT 2001


On Wed, May 16, 2001 at 04:59:35AM +0100, Glynn Clements wrote:
> 
> Eric G. Miller wrote:
[snip]
> > 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?

Yep, used wrong term...

> > 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.

We're both saying the same thing here... parent of second fork is child
of first...

> I think that XDRIVER will have to do proper process management. The
> existing code is really just proof-of-concept.

What do you mean?  Do you have some idea how the XDRIVER could possibly
manage the behavior of the external programs that instigate the drawing
operations?  

I was thinking some kind of "semaphore" like mechanism might work.
Maybe the first child "acquires" a lock (or waits) and the second child
"releases" it when it's done.  No, that doesn't work either, because the
command list would've already been built but would be missing items.
Hmm, unless if it can't get the "lock" it sets a flag which do_events()
would check again later?  Sorry, I'm just brainstorming a little here...

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list