hunt@spar.slb.com (Neil Hunt) (12/21/88)
I have a SunView program in which I accept LOC_DRAG events, but in which I
have not indicated an interest in LOC_TRAJECTORY events. Apparently this
should have the effect that multiple LOC_DRAG events waiting in the event
queue should be compressed into the most recent before delivery to the
process.
Upon receipt of a left button, I invoke a magnifier process, which can be
dragged around over my image display window. This sits in a loop:
while(! event_is_up(event)) {
window_read_event(canvas, event);
compute new magnifier and display. }
When I wrote this, the window_read_event() function also seemed to perform
this collapsing of multiple LOC_DRAG events into the most recent.
However, now it doesn't. This has the effect of causing the magnifier to
lag further and further behind the cursor, as it takes a little longer for
each magnifier repaint than the interval between events. I am sure that
thiss used to work OK on 3.2 Somewhere between 3.2 and 3.5 it broke. It
is still broken at 4.0.1. The 4.0 manual is not clear whether the
compressing feature applies just to events delivered directly, or whether
it should apply to window_read_event() as well.
Has anyone else noticed this behaviour? Is there a magic switch which can
be applied somewhere to allow compression of events as required? In the
meantime I have a horrible workaround, replacing window_read_event with:
canvasfd = window_get(canvas, WIN_FD));
window_read_event(canvas, event)
if(ioctl(casnvasfd, FIONREAD, &ninputs) == 0)
while(ninputs >= sizeof(Event) &&
window_read_event(canvas, event) == 0 &&
!event_is_up(event))
ninputs -= sizeof(event);
which does its own compression of events, but since it crosses the system
call boundary for each event, it is noticeably slower.chuck@trantor.harris-atd.com (Chuck Musciano) (12/31/88)
> When I wrote this, the window_read_event() function also seemed to perform > this collapsing of multiple LOC_DRAG events into the most recent. > However, now it doesn't. Are you using Frame Maker, version 1.3 or earlier? Frame had the annoying problem of modifying the mouse event rate for all windows, causing the exact behavior you describe. If so, you need to get version 1.3b, which fixes the problem. You may have other applications which have modified the tracking rate. Incidentally, the code you describe is the "right" way to solve the problem. Chuck Musciano Advanced Technology Department Harris Corporation (407) 727-6131 ARPA: chuck@trantor.harris-atd.com