[winGRASS] libG11

[Glynn Clements]

Malcolm Blue wrote:

> > -----Original Message-----
> > From: wingrass-admin at grass.itc.it [mailto:wingrass-admin at grass.itc.it]On
> > Behalf Of Mike Thomas
> 
> > v.digit hangs after about five points and doesn't show the line
> > between the
> > mouse cursor and the last digitised point at any stage - my guess is that
> > either "XGetImage()" or the event queueing code is at the heart of the
> > problem.  I'll try getting "XGetImage()" up today.
> >
> 
> That's strange.  I'm able to generate a number of lines on the monitor,
> using the middle button function of d.where (it doesn't show the line until
> after the next point is added either).  d.zoom acts strangely too, it
> doesn't show the 'zoom box' and generally fails for zoom in.
> 
> It's possible that the queue is getting filled up, but it doesn't sound
> likely within the time it would take for you to add just a few points,
> unless mouse move events are continually sent to the event queue.

Get_location_with_line and Get_location_with_box both receive
MotionNotify events, as the line/box have to be continually updated. 
Get_location_with_pointer only receives ButtonPress events.

> We should
> be trying to avoid this anyway.  Glynn had suggested that Expose and
> ConfigureNotify events could accumulate (theoretically), but I don't expect
> it to happen too quickly, unless the queue is too small and doesn't
> dynamically grow or if these events are sent to the event queue when they
> shouldn't be.

Of the three, the least fault tolerant case is
Get_location_with_pointer(), as this doesn't receive MotionNotify
events. If these were erroneously added to the queue, they would
accumulate far more rapidly than e.g. ConfigureNotify.

The issue is that XCheckWindowEvent() will only remove the events
which are actually reported.

In the current version of the code, there shouldn't be any problems,
provided that the event handling is implemented correctly. 
Specifically, any events which don't match the window's event mask
must be discarded rather than queued.

If this were not the case, code which only uses XNextEvent() would
probably continue to work: XNextEvent() would report events which
shouldn't occur, but these would typically just be ignored; the
important point is that they would be removed from the queue.

OTOH, code which only uses XCheckWindowEvent() (i.e. the event loops
in the Get_location_with_* functions) only removes certain types of
events; if other event types were erroneously added to the queue, they
would accumulate.

NB: Expose events are no longer reported, as they aren't required.

> XGetImage() is used by some of the interactive routines (not too many
> though).  Glynn had checked to see which ones used the Panel routines (which
> in turn use XGetImage) and the number is fairly small.  Check his emails
> from late last week for commands to use to test this with.  (Note that
> d.site.labels which was on his list works, so probably only some of the
> options need to use panels.)

Panels are only used if the "-m" switch is given.

-- 
Glynn Clements <glynn.clements at virgin.net>