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

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 <mailto: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
>     <mailto: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 <mailto: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 <mailto: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/20140421/c7fef559/attachment-0001.html>