[plt-scheme] 2htdp/image

From: Todd O'Bryan (toddobryan at gmail.com)
Date: Mon Nov 16 21:28:05 EST 2009

On Mon, Nov 16, 2009 at 9:12 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> On Mon, Nov 16, 2009 at 8:09 PM, Todd O'Bryan <toddobryan at gmail.com> wrote:
>> On Mon, Nov 16, 2009 at 9:03 PM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>>> On Mon, Nov 16, 2009 at 7:58 PM, Nadeem Abdul Hamid <nadeem at acm.org> wrote:
>>>> What's the connection between bitmap and image?
>>> In the old library, images were bitmaps (essentially, with some
>>> optimizations). This led to some performance problems, esp. on older
>>> machines, so in the new library, images are roughly trees of overlaid
>>> images with polygons, ellipses, text, and bitmaps at the leaves.
>>> So, if I have a collection of colors, I can make a bitmap but not
>>> figure out what the tree would have been. You'll be able to see the
>>> difference if you rotate or (especially) scale the image. If it is a
>>> tree of overlaid polygons, say, then scaling will work perfectly, but
>>> the bitmap scaling won't look as good.
>> So images from pasting or Insert Image... won't actually be images
>> anymore, but will be bitmaps?
> All bitmaps are images.
>> In that case, do we need bitmap=? or something like that so we can
>> compare bitmaps to one another?
>> And will you be able to add-line to a bitmap or overlay images on top
>> of bitmaps, etc.?
>> This scares me a little. I understand the motivation, but I'm worried
>> that teaching the difference between images and bitmaps may be a
>> bigger pain than pinholes were. :-) Any way to hide the difference
>> from the user so that we get the speed-up where possible, but the
>> expected semantics where we can't do any better?
> That requires someone better/smarter than me to figure out.

I think I'm confused. If all bitmaps are images, but equality is done
cleverly, what will happen if you do

(equal? (overlay BITMAP (line 20 30 "black"))
        (add-line BITMAP 0 0 20 30 "black"))

And if you have to handle bitmaps anyway, how is color-list->image or
any of the crop functions any more problematic?

In other words, suppose I make an image in DrScheme and save it as a
PNG. When I read it back in, I've lost all the image-y information, so
is it only equal to another bitmap that's pixel-identical, but not to
an image that's pixel-identical (say the one I saved)?

Sorry to be dense, but I'm just trying to understand how this is going
to work when you start mixing user-created images and images loaded
from outside the environment.


Posted on the users mailing list.