I'll test it this evening when I am back home. The animated-canvas class actually keeps two bitmaps - one for painting from and one for drawing to. The swap-bitmaps methods swaps those and repaints the canvas. I'm not sure which of those the new canvas backing store would replace. Doug <div class="gmail_quote">On Mon, Nov 1, 2010 at 9:07 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">At Sun, 31 Oct 2010 16:29:08 -0600, Doug Williams wrote: </div><div class="im">> The animated-canvas library that I have on PLaneT has two examples. The > histogram-test.rkt example works as expected. The lines.rkt example draws a > few lines and then locks up. Adding a (yield) after (send canvas > swap-bitmaps) in line 55 gets it to run - sort of. The animation is fairly > smooth for 10 sets of lines, but is really strange at 50 (for example) - > with this machine on the old GRacket it would be smooth at 100. And, my stop > button implementation doesn't work will - it just sets a global and the > graphics routines exit when they see it set - it eventually stops, but may > require 10 to 15 seconds or so. I suspect that the animated-canvas > functionality for double-buffering may not be needed anymore and the 'flush' > operations are what I need to look at. > > The interactions.ss file in the simulation package on PLaneT also required a > (yield) after line 107 to give the animation effect - there is no double > buffering or anything here. But, with that added, it seems to run fine. </div>I've pushed changes to make the canvas refresh without `yield'. Can you check with the latest version? You're right that double-buffering usually should not be needed anymore, since all canvases now have a backing buffer. As an example, text editors (like the ones in DrRacket) used to have their own backing buffer, and they don't anymore. There are cases where you need precise control over the timing of flushes. The new `suspend-flush' and `resume-flush' methods on `dc<%>' give you extra control over the timing of flushes, and often that extra control is enough. (Text editors use those methods to group a refresh of the editor.) Since `suspend-flush' doesn't absolutely prevent flushes, however, an extra backing buffer would be needed if it's important to never show an intermediate drawing state. Finally, you might still want an explicit backing buffer to stage a complex drawing so that it can be moved onscreen quickly. Slideshow, for example, still draws a next slide offscreen (when it is otherwise idle) so that it can display the slide instantly when you advance the show. </blockquote></div>