[plt-scheme] 2htdp/image questions

On Sun, Apr 18, 2010 at 12:46 PM, Stephen Bloch <sbloch at adelphi.edu> wrote:
>
> On Apr 18, 2010, at 12:39 PM, Robby Findler wrote:
>
>> The new library however is much more suited to shape-based manipulations of images.
>
> Yes, I understand, and I'm very thankful for it.  But as written, it already treats bitmaps as one of the "atomic" kinds of images: if a student copies and pastes a photo from a Web browser and then rotates or scales it, the student will get somewhat jaggy results but not a type error.  And as written, it already needs to be able to render an arbitrary image into a bitmap (for display and equality, if nothing else).
>
> I'm downright looking forward to doing the following demo in class: compare
>
> (scale 5 5 (add-blue-gradient (triangle 10 "solid" "green")))
> (add-blue-gradient (scale 5 5 (triangle 10 "solid" "green")))
>
> and explain the difference.  I think this could be a "teachable moment", even for my non-majors.
>
> Anyway, with the current design, I can write map-image and build-image and get-pixel to produce correct results without inventing a whole new data type.  I can probably even get map-image to be efficient.  But if build-image calls a user-provided function hundreds or thousands of times on the same image, and each of those calls invokes get-pixel a few times, and get-pixel starts by re-rendering the image, performance will really suck and Scheme will look like an utter joke next to Python.

Yes, I won't do that.

>
> I mentioned one solution: "the first time you need to render an image, cache the bitmap".  Perhaps another solution is to turn the "build-image" function I described into another node type in the shape data type.  A pixel-by-pixel transform can appear anywhere in a shape tree (although you might want to normalize it to the top, above overlays).  But I think that would be a more disruptive change, with more non-obvious implications, than the caching idea.

Something along these lines is what I imagine would work well, but I
haven't tried it. Also, pixels are not little squares, so you really
want to treat these transformations as working on point samples, which
fits the more performant version (I think, anyways, but I really think
that this would require someone trying it out to see).

Robby