As a side note, I remember having stumbled on the same issue some while
back, and the way I dealt with it was to refresh based on a random outcome.
Not clean, but it works pretty well as long as the refresh calls are still
close enough.
Laurent
On Thu, Apr 17, 2014 at 12:11 AM, David Vanderson
Matthew Flatt wrote at 04/16/2014 01:56 PM:
(set! needed? #t)
(queue-callback (lambda () (when needed?
(set! needed? #f)
(send this refresh)))
#f) ; = low priority
This is what I'd try first. If it works well
(moved to dev)
On Linux, the attached program shows terrible responsiveness when
dragging points around on the graph. Can anyone else on Linux reproduce
this behavior?
The patch below dramatically improves the responsiveness by forcing the
eventspace to process medium-level events (mouse
You're right that it's about event ordering and not refresh coalescing.
Since mouse events are handled after refreshes, you won't get the next
refresh request until an earlier one is handled, after which the next
mouse event can trigger another refresh request. I think the difference
between
Thanks for the great (and quick!) response. It's good to know that the
ordering is intentional, and to have some nice ways to work around it if
needed.
The reason I thought that refreshes were lower priority was because of
the scrollbar behavior in the program below. On Unix/X, dragging the
5 matches
Mail list logo
