On Mar 24, 2014, at 12:53 PM, John Clements <[email protected]> wrote:
> > On Mar 21, 2014, at 3:19 PM, David Vanderson <[email protected]> > 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 ____________________ Racket Users list: http://lists.racket-lang.org/users
