[plt-scheme] 2htdp/image questions

On Apr 22, 2010, at 8:27 AM, Robby Findler wrote:

>> On Wed, Apr 21, 2010 at 3:33 AM, Stephen Bloch <sbloch at adelphi.edu> wrote:
>>> But why do I (or my students) have to go through a feature-request process
>>> to get additional operations, rather than having an easy way to write them
>>> ourselves?
> 
> One possible answer: you don't. Make a copy of the 2htdp/image and go
> wild. Put it on planet if you think I'm so unresponsive that I won't
> even accept patches.

I've been working on this in the past few days; I'll let you know when I have something that works :-)

> One possible other answer: asking for an easy way to add features to
> library is in fact a feature. :)

I did make such a request: I'd like a way to insert bitmap->bitmap functions into an image tree, or apply bitmap->bitmap functions to the final rendered form of an image.  I'd like this to be easy enough that my first-semester students can do it.

> As for a recent comment here, I don't think that we want to add a
> "rasterize" or "make this be a bitmap" operation to 2htdp/image since
> that brings in a performance model to teach to the students

Let's distinguish between two issues we've been discussing recently.

(1) adding a beginner-friendly way to apply a bitmap->bitmap function to an image.  The simplest form of this (in my original proposal; Matthias described a somewhat different API) would be map-image, which creates an image the same size and shape as the original by mapping the color of each input pixel to the color of the corresponding output pixel.  A more general form would be build-image, which creates an image of a specified size and shape by calling a specified function on each of its (x,y) pixel positions.  I've been working on writing map-image (in my Copious Free Time :-)) but it occurred to me that build-image would benefit a LOT from ...

(2) a way to cache the rendered bitmap form of an image, so that one can make a lot of pixel queries on it, or use it many times at the same magnification, without re-rendering the whole thing each time.  And as Paul has observed, even a large bitmap takes less time to render than a complex image tree, so he would like to be able to build an infrequently-changing background, cache it in bitmap form, and draw other rapidly-changing things on top of it.  Such a mechanism would be purely an optimization: it should have no visible effect on anything except rendering speed and memory use.  I suggested doing this with a "cached-image" wrapper as one more node type in the image tree.

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.

Stephen Bloch
sbloch at adelphi.edu