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 <david.vander...@gmail.com > wrote: > 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 scrollbar > back and forth does lots of paints, but I only actually see a few of them. > > Does that sound like a bug to you? > > > #lang racket/gui > > (define num-on-paint 0) > > (define frame > (new frame% > (label "Refresh") > (width 500) > (height 500))) > > (define (draw-screen canvas dc) > (set! num-on-paint (add1 num-on-paint)) > (sleep 0.1) ; simulate a longer painting effort > (send dc draw-text (~a num-on-paint " paints") 400 70)) > > (define canvas > (new canvas% > (parent frame) > (paint-callback draw-screen) > (style '(no-autoclear hscroll)))) > > (send frame show #t) > > (send canvas init-auto-scrollbars 700 #f 0.0 0.0) > > > > > On 04/16/2014 01:56 PM, Matthew Flatt wrote: > >> 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 Unix/X and Windows may be that Windows sends fewer mouse >> events. >> >> There are trade-offs here, but my experience is that ordering input >> events before refresh does not work well in general. To trigger >> refreshes at a lower priority in this case, you could use Neil's >> suggestion or change >> >> (send this refresh) >> >> to >> >> (set! needed? #t) >> (queue-callback (lambda () (when needed? >> (set! needed? #f) >> (send this refresh))) >> #f) ; => low priority >> >> where `needed?` is a field that's initially #f. >> >> At Wed, 16 Apr 2014 13:33:02 -0400, David Vanderson wrote: >> >>> (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 movement) before >>> refresh events. Without the patch, each mouse drag causes a paint. >>> With it, multiple mouse drags are processed before a paint. >>> >>> >>> I'm unsure about this fix. Windows doesn't show the problem (I don't >>> have a mac to test), so I think it's just a GTK issue. >>> >>> My guess is that the gui layer is relying on the native libraries to >>> coalesce multiple refresh requests (but this is not working with GTK). >>> Can anyone confirm this? >>> >>> Thanks, >>> Dave >>> >>> >>> >>> diff -ru >>> racket-6.0_clean/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt >>> racket-6.0/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt >>> --- racket-6.0_clean/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt >>> 2014-02-18 12:27:43.000000000 -0500 >>> +++ racket-6.0/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt >>> 2014-04-16 09:41:16.810993955 -0400 >>> @@ -300,8 +300,8 @@ >>> (lambda (_) #f)) >>> (or (first hi peek?) >>> (timer-first-ready timer peek?) >>> - (first refresh peek?) >>> (first med peek?) >>> + (first refresh peek?) >>> (and (not peek?) >>> sync? >>> ;; before going >>> with low-priority events, >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> [text/plain "graph_ui.rkt"] [~/Desktop & open] [~/Temp & open] >>> _________________________ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >>> >> > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
