[plt-scheme] 2htdp/image questions

On Thu, Apr 22, 2010 at 02:44:41PM -0400, Stephen Bloch wrote:
> 
> 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.

It almost (but not quite) sounds like you need a way to access 
something like the GEGL library from PLT Schene.

-- hendrik