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

Perhaps it isn't big-bang per se.  I need to wrap up some end-of-semester things this week, but 

1. I'll will try to find some time to profile your program possibly with Vincent's spanking-new feature-specific profiler. If we find a good set up, we'll send instructions. 

2. Since I am working in the blind (no linux box that has similar problems), I may also rewrite the program so that it by passes big-bang and uses the canvas directly. That will give us a clue whether we're looking at problems in the complex layer of big-bang or the more complex layer of canvases and things. 

-- Matthias








On Apr 22, 2014, at 7:30 AM, Laurent wrote:

> 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
> 
> 
> ____________________
>  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/0de7ef3d/attachment-0001.html>