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 <mailto: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
    <mailto: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 <mailto: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 <mailto: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

Reply via email to