<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Perhaps it isn't big-bang per se. I need to wrap up some end-of-semester things this week, but </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>-- Matthias</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><div><div>On Apr 22, 2014, at 7:30 AM, Laurent wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>Thank you all for your answers. The problem seems to be on my end then.<br></div>However, some other graphic programs that draw in a canvas are not slow on my computer.<br><br>Does `big-bang` do something in particular regarding graphics?<br>
<br>Laurent<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 21, 2014 at 10:29 PM, David Vanderson <span dir="ltr"><<a href="mailto:david.vanderson@gmail.com" target="_blank">david.vanderson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
Dave<div><div class="h5"><br>
<br>
<div>On 04/21/2014 11:10 AM, Laurent wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>My version of Cairo is 2.11000.2. What's yours, Sean?<br>
</div>
(probably: ls /usr/lib/i386-linux-gnu/libcairo.so*)<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Apr 21, 2014 at 4:51 PM,
Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If the
versions of Cairo are the same, then that eliminates one<br>
possible route of inquiry.<br>
<span><font color="#888888"><br>
Robby<br>
</font></span>
<div>
<div><br>
On Mon, Apr 21, 2014 at 9:45 AM, Laurent <<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>>
wrote:<br>
> Thanks Sean.<br>
> (I forgot to mention that I was testing on Racket
6.0.1.4).<br>
> Apparently it does not lag on your machine, so it
might be particular to my<br>
> machine then? Strange.<br>
><br>
><br>
> On Mon, Apr 21, 2014 at 4:32 PM, Sean Kanaley
<<a href="mailto:skanaley@gmail.com" target="_blank">skanaley@gmail.com</a>>
wrote:<br>
>><br>
>> Here's my log after pasting the source into
command-line racket 6.0,<br>
>> Ubuntu 12.04 32-bit:<br>
>><br>
>> to-draw at 1649<br>
>><br>
>> to-draw: cpu time: 0 real time: 2 gc time: 0<br>
>> on-key a at 2934<br>
>> to-draw at 2934<br>
>><br>
>> to-draw: cpu time: 0 real time: 2 gc time: 0<br>
>> on-key s at 2970<br>
>> to-draw at 2970<br>
>><br>
>> to-draw: cpu time: 4 real time: 3 gc time: 0<br>
>> on-key d at 3044<br>
>> on-key f at 3044<br>
>> to-draw at 3045<br>
>><br>
>> to-draw: cpu time: 0 real time: 0 gc time: 0<br>
>> to-draw at 3069<br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> on-key a at 3198<br>
>> on-key s at 3198<br>
>> to-draw at 3199<br>
>><br>
>> to-draw: cpu time: 4 real time: 3 gc time: 0<br>
>> to-draw at 3329<br>
>><br>
>> to-draw: cpu time: 4 real time: 1 gc time: 0<br>
>> to-draw at 3392<br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> on-key g at 3430<br>
>> on-key j at 3430<br>
>> on-key k at 3430<br>
>> to-draw at 3430<br>
>><br>
>> to-draw: cpu time: 4 real time: 1 gc time: 0<br>
>> to-draw at 3467<br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> on-key a at 3504<br>
>> on-key l at 3504<br>
>> to-draw at 3505<br>
>><br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> to-draw at 3547<br>
>><br>
>> to-draw: cpu time: 4 real time: 1 gc time: 0<br>
>> to-draw at 3572<br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> on-key h at 3602<br>
>> to-draw at 3602<br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> on-key k at 3659<br>
>> on-key ; at 3659<br>
>> to-draw at 3659<br>
>><br>
>> to-draw: cpu time: 4 real time: 3 gc time: 0<br>
>> to-draw at 3689<br>
>><br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> to-draw at 3725<br>
>><br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>> to-draw at 3776<br>
>> to-draw: cpu time: 0 real time: 1 gc time: 0<br>
>><br>
>><br>
>><br>
>> On Mon, Apr 21, 2014 at 10:00 AM, Laurent
<<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> I have a 2htdp/universe program that used
to run fast enough a few months<br>
>>> ago, but now it is very slow and not
usable.<br>
>>> The slowness seems to be because of the
on-screen rendering, and not<br>
>>> because of the generation of the image.<br>
>>><br>
>>> Here is a stripped-down version that
shows this behavior:<br>
>>> <a href="https://gist.github.com/Metaxal/11142941" target="_blank">https://gist.github.com/Metaxal/11142941</a><br>
>>><br>
>>> In the following log, you see that the
`on-key` events are very close one<br>
>>> to the other (in milliseconds after the
beginning of the program), but the<br>
>>> corresponding `to-draw` events are
separated by more than a second, even<br>
>>> though generating the image (cpu time)
takes almost no time:<br>
>>><br>
>>> on-key a at 6906<br>
>>> on-key u at 6912<br>
>>> on-key i at 6912<br>
>>> on-key e at 6913<br>
>>> to-draw at 6913<br>
>>> to-draw: cpu time: 4 real time: 3 gc
time: 0<br>
>>> to-draw at 8598<br>
>>> to-draw: cpu time: 4 real time: 2 gc
time: 0<br>
>>> to-draw at 11948<br>
>>> to-draw: cpu time: 4 real time: 2 gc
time: 0<br>
>>> to-draw at 13631<br>
>>> to-draw: cpu time: 0 real time: 2 gc
time: 0<br>
>>> to-draw at 161839<br>
>>> to-draw: cpu time: 4 real time: 9 gc
time: 0<br>
>>><br>
>>> During those long seconds, Xorg is almost
at 100% cpu.<br>
>>><br>
>>> However, using an empty scene instead of
an image is fast.<br>
>>> The time also depends on the size of the
grid.<br>
>>><br>
>>> I'm using Ubuntu 12.04 64bits.<br>
>>> I have tried to replicate the behavior on
older versions of racket (5.3.1<br>
>>> and 5.90.0.9) but it's the same. So maybe
the problem is not on Racket's<br>
>>> side but something has changed in Ubuntu?<br>
>>><br>
>>> Does anyone else see the same behavior,
either on the same platform or on<br>
>>> a different one?<br>
>>><br>
>>> Thanks,<br>
>>> Laurent<br>
>>><br>
>>><br>
>>> ____________________<br>
>>> Racket Users list:<br>
>>> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
>>><br>
>><br>
><br>
><br>
> ____________________<br>
> Racket Users list:<br>
> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>____________________
Racket Users list:
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a>
</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>
____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a><br></blockquote></div><br></body></html>