[racket] limiting refresh rate of scroll bar calls to canvas%'s 'draw'

On Mar 21, 2014, at 3:19 PM, David Vanderson <david.vanderson at gmail.com> wrote:

> 
> On 03/21/2014 02:16 PM, John Clements wrote:
>> 2) upstream, inherit from canvas% and add code to limit the rate of calls to draw. I haven’t looked at the code yet, but this might be my best bet.
> I tried overriding "refresh", and there's a tempting mention in the docs that "(Multiple refresh requests before on-paint can be called are coaleced into a single on-paint call.)"  This does work if you have code that is explicitly calling "refresh".
> http://docs.racket-lang.org/gui/canvas___.html
> 
> Unfortunately it looks like "refresh" doesn't get called by lower-level stuff like scrollbars.  Can anyone confirm this?
>> 3) one other thing occurs to me, though; it looks to me like calls to ‘draw’ are stacking up in an eventspace queue, and that seems like a mistake; if there’s a draw in progress, and calls to draw in the queue, it seems like another ‘draw’ should at a minimum squash the ones in the queue. Perhaps that’s painful to implement, or there’s a good reason for allowing all of the queued calls to complete?
>> 
> I'm also seeing this (on Linux), or at least, it seems like many paints are happening but the back buffer is not being flushed to the screen.  When I run the attached code, and then scroll a lot, then I see more dots printed to the console than frames being shown.
> 
> When I run it on Windows (from console) then things look much better, and it looks like I'm seeing every paint.  
> 
> When I run it inside DrRacket on Windows I see no updates while scrolling until letting go of the scrollbar (different issue?)
> 
> What do you see on Mac?

I see something a lot like what you see on Windows.

BUT.

It looks like the problem here is the “printf”. Commenting out the printf and the flush-output (and yes, both are necessary) restores sensible behavior; the scrolling is live (or as live as it’s going to be with a 1/10 second delay in draw), and there don’t appear to be a bunch of queued calls to draw.

This leads me to believe that my initial problem was likely due to the diagnostic printfs that I had inserted in order to measure the performance.

Thanks for the detective work!

John Clements