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. Thanks for the detective work! John Clements ____________________ Racket Users list: http://lists.racket-lang.org/users
