Re: [racket-users] Canvas animation slowness

Thanks for taking a look. Unfortunately I was not targeting what is drawn, but how it is drawn. Think 100 colors instead of 2, in which case your optimization would gain only 1/100. (I was just too lazy to actually create 100 brushes.) I'm pretty sure this should not be as slow as that. (A quick

Re: [racket-users] Canvas animation slowness

I conjecture method calls contribute to the expense. Here is a way to eliminate ~~ half the calls for the inner loop: (define (draw-to-dc dc) (send dc set-pen no-pen) (send dc set-brush brush-red) (send dc draw-rectangle 0 0 XMAX YMAX) (send dc set-brush brush-blue) (for* ([x (in-rang

[racket-users] Canvas animation slowness

I'm surprised by the slowness of animations in a canvas. Here's a simple stress test: https://gist.github.com/Metaxal/73897e7bac5332054511 For a 100x100 board it takes 2 seconds to draw 10 random frames (outside DrRacket of course). I was expecting at least 10x more frames per second. Is there an

Re: [racket-users] 6.2 regression in running tests?

At Wed, 15 Jul 2015 22:48:26 -0300, Gustavo Massaccesi wrote: > But perhaps the problem is in the code that tracks the single_use > value. After 'dup' is applied, 'rep' is not long a singled used > function. Yes, I think that's the problem. I thunk I have a repair to update single-use tracking app