[plt-scheme] 2htdp/image

> Yes, and the current htdp/image library does this (and so your
> libraries inherit this behavior, I believe).

I hadn't realized that; I thought they were just being stored as  
bitmaps.  I would have written "tiles" differently....

>
>> Do you really need a bounding box precomputed (as opposed to  
>> computing it
>> only when you actually need it)?
>
> No, but most operations need it, so it will be computed. Repeated
> rotations (without intervening overlays) won't need it, but it didn't
> seem worth going the lazy route for that, since it seems uncommon.

Any sequence of {rotations, reflections, scalings, translations,  
skews} doesn't need it.  Of course, it's really easy to compute for  
reflections, scalings, and translations, but still not technically  
necessary.

>
>> How about replacing the bounding box with a convex hull?  ...

> I thought about that too, but it didn't seem worth the effort because
> it won't give an asymptotic speed up.

No, by itself it won't, but it means you're no longer tied to "boxes"  
parallel to the axes, so you no longer have an obligation to choose  
such a box after each operation.

As a bonus, cropping can be implemented by ONLY operating on the  
convex hull (not touching the bitmap unless it's convenient), and in  
most cases will have the effect of reducing the number of vertices.

> That possibility is still open, of course, if we do run into
> performance problems (but it seems like premature optimization at this
> point).

Fair enough.

>
>>
>> ... "conservative convex hull"...

> But then the bounding boxes will start getting less precise, no? You
> don't want a situation where repeating a series of operations and
> (what seem like) inverses grows the bounding box. Can you avoid that
> here?

What operations increase the number of vertices in a convex hull?   
Overlay, or (rarely) crop.  Neither of which has an inverse.

I guess if the "certain distance" within which vertices get merged  
were an absolute number, scaling could trigger vertex-merging.  So  
make it a relative radius, or just don't do vertex-merging unless the  
number of vertices gets annoyingly large -- which it never will from  
invertible linear operations.

Hmm... What would have an "annoyingly large" convex hull?  A circle or  
an ellipse; good thing nobody ever uses those :)


Steve