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
