It certainly can lose sharpness if you scale (as the freezing process
is basically just rendering them into bitmaps and then drawing the
bitmaps and scaling the bitmaps looses quality because the scaling for
process of bitmaps doesn't have the geometric information to work
with).
It seems like, with fractals, the fact that you have self-similarity
means that you can have repeated images in a dag-like structure (like
the example on the webpage) where freezing might help.
Another approach here would be to help me do performance debugging of
2htdp/image :). You could write the code directly as imperative calls
to the dc<%> interface and see how that compares. If there's a
significant difference, that suggests we might be able to find a way
to speed up 2htdp/image.
You'd use something like this:
#lang racket/gui
(define (draw-it dc w h)
;; fractal drawing code goes here
(send dc draw-ellipse (/ w 4) (/ h 4) (/ w 2) (/ h 2)))
(define f (new frame% [label ""] [width 200] [height 200]))
(define c (new canvas% [parent f]
[paint-callback
(λ (c dc)
(define-values (w h) (send c get-client-size))
(send dc set-smoothing 'aligned)
(draw-it dc w h))]))
(send f show #t)
On Mon, May 4, 2015 at 4:03 PM, Alexander D. Knauth
<alexan...@knauth.org> wrote:
>
> On May 4, 2015, at 12:49 AM, gfb <g...@cs.toronto.edu> wrote:
>
>> Those are beautiful.
>
> Thanks!
>
>> First, make sure in Choose Language / Show Details that it's set to "No
>> debugging or profiling", and that "Preserve stacktrace" not set.
>
> Already have that, but thanks for checking.
>
>> The 2htdp/image library has immutable images, so the image you're creating
>> contains all the line drawing "unexecuted" until you display or freeze it.
>>
>> There's a lot of symmetry, so rather than passing an image as a parameter
>> can you express the algorithm as returning one of the component images at
>> each level, then rotating and combining it with itself? As long as the
>> result is symmetric that will create a rather narrow Direct Acyclic Graph of
>> images.
>
> I thought about doing that, and that’s what an example in the docs does, but
> I didn’t because I was afraid I would lose precision of exactly where the
> lines go, and since most of these fractals have multiple layers, that’s
> important.
> From the example in the docs, at the smaller scales it doesn’t look sharp or
> accurate to me, and would it really improve performance? Since they would be
> all rotated from each other, I don’t think I would be able to reuse
> computations very much.
>
>> You can then also experiment with freezing some of those intermediate
>> images, especially at the top levels where rotating a bitmap might be faster
>> than executing the drawing actions in a rotated co-ordinate system. But
>> that's speculation, not experience.
>
> The documentation for freeze says that freeze isn’t going to be helpful for
> images that will be scaled or rotated?
> If it were a serpinski carpet, I think this could probably help a lot, but
> for what I’m doing, I don’t think it would.
>
>> Other than that, consider drawing directly into a mutable bitmap% from
>> racket/draw, or explore images/flomap.
>
> I haven’t looked at images/flomap yet, but it looks interesting.
>
>> Then there are the possibilities of Typed Racket optimizations, and
>> profiling and the Optimization Coach in general.
>
> I didn’t want to try typed racket because 2htdp/image isn’t written in typed
> racket, so there would be contract checks on every image function call. If I
> have time to try images/flomap that won’t be a problem though.
> I didn’t want to try profiling because in my experience it slows things way
> down, and I don’t want to do that on code that already takes at least three
> days to run.
> I’ve already tried optimization coach on my code, but it didn’t have much
> help to give.
>
>
> On May 4, 2015, at 7:01 AM, Robby Findler <ro...@eecs.northwestern.edu> wrote:
>
>> Just in case: freezing an image requires actually rendering it but
>> constructing the image doesn't (it just builds a tree/dag matching fairly
>> closely to the image operations you used). So the time for constructing the
>> images can be pretty different than freezing them.
>>
>> Drawing a frozen image is a bitmap copy (and can be faster than rendering it
>> if it is a complex image) so freezing the intermediate ones might help if
>> intermediate ones are drawn many times.
>
> That’s why I started freezing these fractals. They were taking a long time to
> draw in DrRacket, and then taking a long time to save as an image file on my
> computer. So freezing them meant that it took a long time to freeze them, but
> after that both drawing them in DrRacket and saving them to my computer were
> quick. Plus I could use time to see how long it took to construct it versus
> freeze it.
>
> The way I have it right now, I have a recursive function which uses a bunch
> of calls to scene+line, so I don’t have any points where there are
> intermediate images that are drawn many times that it would be helpful to
> freeze. I could restructure it to do that, but from the example in the docs,
> it looks like I’d loose sharpness, and the ability to control exactly where
> everything is, so that the things in all the different layers line up
> properly.
>
>
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
