[plt-scheme] 2htdp/image questions

>
> In htdp/image, we were able to do this: if
>
> (define (draw-handler blah) (overlay blah (big-complex-expression)))
>
> was taking too long to render, you would instead write
>
> (define BACKGROUND (big-complex-expression))
> (define (draw-handler blah) (overlay blah BACKGROUND))
>
> and the animation would run much more quickly because BACKGROUND was stored as a bitmap.
>
> In 2htdp/image (as Paul discovered), this trick doesn't work any more because the image is actually stored as big-complex-expression, to be interpreted at rendering time.  There are very good reasons for making that choice, but it would be nice to be able to say
>
> (define BACKGROUND (cache-image (big-complex-expression)))
> (define (draw-handler blah) (overlay blah BACKGROUND))
>
> and get the same efficiency gain as before.  I wouldn't teach this in a beginning course, although I would mention it to an individual student like Paul's.

May I suggest that this is not a good idea? It breaks the abstraction
that the HtDP languages and universe provide which makes the teaching
of programming to beginners possible. The introduction of something
like cache-image all of the sudden means that not all images are
alike. The _beginner_ must now think about the machinery that renders
images in addition to thinking about the problem/game they are working
on. IMHO, that is not the way to go.

While I am at it, why does it matter that universe renders choppy
images after a few hundred or thousand overlayed images? Universe,
AFAIK, is not intended to be a industrial-strength game development
platform. It is supposed to offer an abstraction that allows beginners
to write games and simulations. We ought to work within the
constraints it comes with and discourage images that it can not handle
well if it means breaking the abstraction it offers. Do beginners
really need to render images composed of hundreds or thousands of
smaller images? If so, it is time for those students to move on to a
industrial-strength development platform. As is familiar to FPers,
thinking about the machine is not where the focus should be.

-- 

Cheers,

Marco