[racket-dev] gui responsiveness

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.vanderson at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20140417/388cb0e7/attachment.html>