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 <ro...@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 > <ro...@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 <gre...@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 >>> >> > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
