[racket] 2htdp/image Sierpinski

Okay, freeze is now pushed. If you use it, let me know how it works
out. (Suggestions for a different name are welcome (well, until the
next release anyways :).)

Robby

On Thu, Dec 16, 2010 at 9:08 AM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> I spent some time looking into exploiting the sharing and it gets
> pretty painful and even at best, it works only when the shared copies
> are translated versions of each other (sharing that goes thru
> rotations or scales would not be able to effectively exploit the
> sharing as far as I can see).
>
> So I guess we're still left with some 'cache'-like thing (that freezes
> the image as a bitmap and then draws the bitmap afterwards) as the
> best option (although not a great one).
>
> Robby
>
> On Sun, Oct 31, 2010 at 8:24 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> There are a few things going on here. When you say (carpet 300 "red"),
>> you're actually asking Racket to draw more than 42,000 squares, which
>> can take some time (plus more than 20,000 intermediate overlaid shapes
>> to work thru to get to the squares). Also, the redrawing you're seeing
>> isn't specific to this image. It happens for all of them, but you just
>> don't see it because the drawing typically finishes faster than you
>> can tell. (FWIW, the redrawing aspect of it will be slightly better in
>> Gracket2 in that it will do all that drawing offscreen instead of
>> letting you see those intermediate states.)
>>
>> Overall, tho, we'd like to be able to support this kind of thing, but
>> we need to do a better job. As I'm writing this, I wonder if we could
>> exploit the sharing in the image. In your example, there are only 11
>> calls to 'square' that turn into those 42,000 different squares spread
>> around. If we could detect and exploit the sharing somehow that could
>> lead to a big speed up. (But this is just a half-formed thought;
>> nothing may come of it.)
>>
>> Robby
>>
>> On Sat, Oct 30, 2010 at 11:18 PM, Gregor Kiczales <gregor at cs.ubc.ca> wrote:
>>> In 2htdp/image the implementations of Sierpinski triangle and carpet are nice and simple, which is great for using them in class.
>>>
>>>
>>> (define (carpet size c)
>>>  (if (<= size 2)
>>>      (square size "outline" c)
>>>      (local [(define sub (carpet (/ size 3) c))
>>>              (define ctr (square (/ size 3) "solid" "white"))]
>>>        (overlay (square size "outline" c)
>>>                 (above (beside sub sub sub)
>>>                        (beside sub ctr sub)
>>>                        (beside sub sub sub))))))
>>>
>>> But...  (carpet 200 "red") produces some strange behavior on my Mac. (carpet 300 "red") is even worse.  The image draws very slowly, which I assume comes from the way the image is actually composed of all the composed images rather than a single bitmap. But, stranger than that, it seems to need to draw itself several times.
>>>
>>> Also I would have thought that 'forcing' the image by actually drawing it would save the bitmap so that future drawing was faster. But I may not understand how this is actually working.
>>>
>>> Is this style of using above, beside and friends to make something this big intended to work? Or is there a different style I should be using?
>>>
>>>
>>> _________________________________________________
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/users
>>>
>>
>