Thank you all for your answers. The problem seems to be on my end then. However, some other graphic programs that draw in a canvas are not slow on my computer.
Does `big-bang` do something in particular regarding graphics? Laurent On Mon, Apr 21, 2014 at 10:29 PM, David Vanderson <david.vander...@gmail.com > wrote: > It's fast for me - Linux Mint, both Racket 6.0 and 6.0.1.5 (from git just > now) with cairo 2.11200.2. > > Dave > > > On 04/21/2014 11:10 AM, Laurent wrote: > > My version of Cairo is 2.11000.2. What's yours, Sean? > (probably: ls /usr/lib/i386-linux-gnu/libcairo.so*) > > > On Mon, Apr 21, 2014 at 4:51 PM, Robby Findler < > ro...@eecs.northwestern.edu> wrote: > >> If the versions of Cairo are the same, then that eliminates one >> possible route of inquiry. >> >> Robby >> >> On Mon, Apr 21, 2014 at 9:45 AM, Laurent <laurent.ors...@gmail.com> >> 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 <skana...@gmail.com> >> 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 <laurent.ors...@gmail.com> >> >> 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: >> >>> https://gist.github.com/Metaxal/11142941 >> >>> >> >>> 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: >> >>> http://lists.racket-lang.org/users >> >>> >> >> >> > >> > >> > ____________________ >> > Racket Users list: >> > http://lists.racket-lang.org/users >> > >> > > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > > >
____________________ Racket Users list: http://lists.racket-lang.org/users
