<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Apr 18, 2010, at 9:07 AM, Robby Findler wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">That is a bad idea for performance reasons (computing</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the bitmap is far more expensive than any of the other things that get</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">done to images) but image equality has to do that (in the fallback</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">slow path), so it would not be too hard to add a get-pixel function</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">that first computed the image and the returned the pixel.</div></blockquote><div><br></div>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.</div><div><br></div><div>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....</div><div><br><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; ">Note that the current design of the image api works hard to avoid</div></blockquote></div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">working with bitmaps not only because it is inefficient, but also</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">because you cannot have a high quality rotate or scale functions</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(things will get pixelated).</div></blockquote><div><br></div><div>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 :-)</div><div><br></div></div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; ">Also perhaps worth noting, such loops are probably easily</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">parallelizable, in most cases. I'm not sure if futures are up to the</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">task or not, tho.</div></blockquote><div><br></div>Yes, that was my objection to writing it as loops with integer indices.</div><div><br></div><div><blockquote type="cite"></blockquote></div><br><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>Stephen Bloch</div><div><a href="mailto:sbloch@adelphi.edu">sbloch@adelphi.edu</a></div><div><br class="webkit-block-placeholder"></div></span><br class="Apple-interchange-newline"> </div><br></body></html>