Re: [racket-dev] gui responsiveness

2014-04-17 Thread Laurent
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

Re: [racket-dev] gui responsiveness

2014-04-17 Thread Neil Van Dyke
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

[racket-dev] gui responsiveness

2014-04-16 Thread David Vanderson
(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

Re: [racket-dev] gui responsiveness

2014-04-16 Thread Matthew Flatt
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

Re: [racket-dev] gui responsiveness

2014-04-16 Thread David Vanderson
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