[plt-scheme] 2htdp/image

On Wed, Nov 18, 2009 at 4:24 PM, Stephen Bloch <sbloch at adelphi.edu> wrote:
>>> 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.

Yes, right. When those are in the library then the tradeoffs may change.

>>
>>> 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.

Cropping still has the other problem that it adds to the set of images
expressible by the image library and thus has some non-trivial
implications on equality. I'm not sure how that would go. We could go
to a most post-script (or dc-path%)-like model, but even there I think
that cropping increases the set of expressible images (altho I'm not
sure; I'm not up to speed on beziers enough to be sure).

Anyways, that's definitely a problem for another (very very rainy) day.

Robby