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 <[email protected]>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 >
____________________ Racket Users list: http://lists.racket-lang.org/users
