[plt-scheme] 2htdp/image questions

On Apr 18, 2010, at 9:07 AM, Robby Findler wrote:

> That is a bad idea for performance reasons (computing
> the bitmap is far more expensive than any of the other things that get
> done to images) but image equality has to do that (in the fallback
> slow path), so it would not be too hard to add a get-pixel function
> that first computed the image and the returned the pixel.

Yes, I know; that's why I suggested not computing the bitmap until  
you need it, but then caching it for future use -- get-pixel, or  
equality, or display, or whatever.  If you mutate any other aspect of  
the image, you would presumably clear the cache.

BTW, if two images both already had cached bitmaps, would it be  
faster or slower to compare the bitmaps than to do the usual tree- 
traversal equality?  I guess that would depend on the size of the  
bitmaps, and the complexity of the tree....

> Note that the current design of the image api works hard to avoid
> working with bitmaps not only because it is inefficient, but also
> because you cannot have a high quality rotate or scale functions
> (things will get pixelated).

OTOH, there are plenty of easily-understood transforms that ARE best  
described in terms of bitmaps.  The difference between applying such  
a transform before or after a rotate-and-scale would be a Teachable  
Moment :-)

> Also perhaps worth noting, such loops are probably easily
> parallelizable, in most cases. I'm not sure if futures are up to the
> task or not, tho.

Yes, that was my objection to writing it as loops with integer indices.



Stephen Bloch
sbloch at adelphi.edu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100418/e656a9ba/attachment.html>