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

Probably a silly question: Are you drawing in a bitmap (buffer) so that
each calls to the `paint-callback` that refreshes the canvas only does a
copy of a section of the bitmap?

Also, just in case, `canvas%` can be initialized with `[style
'(no-autoclear)]` to avoid being erased before each call to
`paint-callback`.

Laurent


On Fri, Mar 21, 2014 at 7:16 PM, John Clements <clements at brinckerhoff.org>wrote:

> In my rsound package, I've enabled scroll bars for viewing sounds. Drawing
> a block takes a long time, though--about 60ms on my i7 mac.  That's way too
> slow for interactive scrolling; a couple of hundred update messages will
> bog things down completely.
>
> To fix this, I'd like to limit the rate of calls to "draw". I can see a
> couple of possibilities:
>
> 1) Keep a timer, and only draw every so often. I implemented this, then
> realized that the canvas is erased before the call to draw, so I wind up
> with a blank screen most of the time, and it doesn't get drawn
> eventually--it stays blank.
>
> 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.
>
> 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?
>
> Thanks in advance for any suggestions!
>
> John
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140321/3e0856dc/attachment.html>