<div dir="ltr"><div>My version of Cairo is 2.11000.2. What's yours, Sean? </div>(probably: ls /usr/lib/i386-linux-gnu/libcairo.so*) <div class="gmail_extra"> <div class="gmail_quote">On Mon, Apr 21, 2014 at 4:51 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If the versions of Cairo are the same, then that eliminates one possible route of inquiry. Robby <div><div> On Mon, Apr 21, 2014 at 9:45 AM, Laurent <<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>> wrote: > Thanks Sean. > (I forgot to mention that I was testing on Racket 6.0.1.4). > Apparently it does not lag on your machine, so it might be particular to my > machine then? Strange. > > > On Mon, Apr 21, 2014 at 4:32 PM, Sean Kanaley <<a href="mailto:skanaley@gmail.com" target="_blank">skanaley@gmail.com</a>> wrote: >> >> Here's my log after pasting the source into command-line racket 6.0, >> Ubuntu 12.04 32-bit: >> >> to-draw at 1649 >> >> to-draw: cpu time: 0 real time: 2 gc time: 0 >> on-key a at 2934 >> to-draw at 2934 >> >> to-draw: cpu time: 0 real time: 2 gc time: 0 >> on-key s at 2970 >> to-draw at 2970 >> >> to-draw: cpu time: 4 real time: 3 gc time: 0 >> on-key d at 3044 >> on-key f at 3044 >> to-draw at 3045 >> >> to-draw: cpu time: 0 real time: 0 gc time: 0 >> to-draw at 3069 >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> on-key a at 3198 >> on-key s at 3198 >> to-draw at 3199 >> >> to-draw: cpu time: 4 real time: 3 gc time: 0 >> to-draw at 3329 >> >> to-draw: cpu time: 4 real time: 1 gc time: 0 >> to-draw at 3392 >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> on-key g at 3430 >> on-key j at 3430 >> on-key k at 3430 >> to-draw at 3430 >> >> to-draw: cpu time: 4 real time: 1 gc time: 0 >> to-draw at 3467 >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> on-key a at 3504 >> on-key l at 3504 >> to-draw at 3505 >> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> to-draw at 3547 >> >> to-draw: cpu time: 4 real time: 1 gc time: 0 >> to-draw at 3572 >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> on-key h at 3602 >> to-draw at 3602 >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> on-key k at 3659 >> on-key ; at 3659 >> to-draw at 3659 >> >> to-draw: cpu time: 4 real time: 3 gc time: 0 >> to-draw at 3689 >> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> to-draw at 3725 >> >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> to-draw at 3776 >> to-draw: cpu time: 0 real time: 1 gc time: 0 >> >> >> >> On Mon, Apr 21, 2014 at 10:00 AM, Laurent <<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>> >> wrote: >>> >>> I have a 2htdp/universe program that used to run fast enough a few months >>> ago, but now it is very slow and not usable. >>> The slowness seems to be because of the on-screen rendering, and not >>> because of the generation of the image. >>> >>> Here is a stripped-down version that shows this behavior: >>> <a href="https://gist.github.com/Metaxal/11142941" target="_blank">https://gist.github.com/Metaxal/11142941</a> >>> >>> In the following log, you see that the `on-key` events are very close one >>> to the other (in milliseconds after the beginning of the program), but the >>> corresponding `to-draw` events are separated by more than a second, even >>> though generating the image (cpu time) takes almost no time: >>> >>> on-key a at 6906 >>> on-key u at 6912 >>> on-key i at 6912 >>> on-key e at 6913 >>> to-draw at 6913 >>> to-draw: cpu time: 4 real time: 3 gc time: 0 >>> to-draw at 8598 >>> to-draw: cpu time: 4 real time: 2 gc time: 0 >>> to-draw at 11948 >>> to-draw: cpu time: 4 real time: 2 gc time: 0 >>> to-draw at 13631 >>> to-draw: cpu time: 0 real time: 2 gc time: 0 >>> to-draw at 161839 >>> to-draw: cpu time: 4 real time: 9 gc time: 0 >>> >>> During those long seconds, Xorg is almost at 100% cpu. >>> >>> However, using an empty scene instead of an image is fast. >>> The time also depends on the size of the grid. >>> >>> I'm using Ubuntu 12.04 64bits. >>> I have tried to replicate the behavior on older versions of racket (5.3.1 >>> and 5.90.0.9) but it's the same. So maybe the problem is not on Racket's >>> side but something has changed in Ubuntu? >>> >>> Does anyone else see the same behavior, either on the same platform or on >>> a different one? >>> >>> Thanks, >>> Laurent >>> >>> >>> ____________________ >>> Racket Users list: >>> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >>> >> > > > ____________________ > Racket Users list: > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> > </div></div></blockquote></div> </div></div>