[racket] big-bang is slow to render on screen?

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.vanderson at 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 <
> robby at 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.orseau at 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 <skanaley at 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.orseau at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140422/656127d9/attachment.html>