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

On Mar 24, 2014, at 12:53 PM, John Clements <clements at brinckerhoff.org> wrote:

> 
> 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.

Final resolution: Yes. Eliminating my diagnostic printf has *completely* resolved my performance problem.

Sorry for the noise.

John Clements