<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com">oliver@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Yeah, that seems likely, since none of you implemented the higher-DPI<br>
ImageData in your first versions. :-(<br>
</blockquote>
<br></div>
WebKit's implementation has always worked with high dpi backing stores and follows the spec accordingly.<br><font color="#888888">
<br></font></blockquote><div> </div></div>Under what circumstances do you use more than one device pixel per CSS pixel? Does it require the user to turn on UI scaling on Mac?<br><br>Regardless, I bet that most people using Webkit to write scripts using getImageData still get it wrong, because they have normal screens. Implementing high-res backing store in more browsers won't solve this problem, not until the average developer has a high-dpi screen. But I repeat myself.<br></blockquote><div><br></div><div>Indeed -- i was merely commenting that there was actually a "correct" implementation -- i am still of the opinion that exposing image data was a bad thing and that a filtering API would have been superior. Oh well, the past is the past and we must now live with it. :-/</div><div><br></div><div>--Oliver</div><div><br></div></div></body></html>