<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><html>On Feb 10, 2008, at 3:08 PM, Robert O'Callahan wrote:</html><br class="Apple-interchange-newline"><blockquote type="cite">On Feb 11, 2008 11:49 AM, Ian Hickson <<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If we have one API, high-res only:<br><br> People who use it correctly:<br> get good results both today and tomorrow.<br> People who use it wrongly:<br> get good results today.<br> will get cropped or visibly wrong results tomorrow.<br> <br>If we have two APIs:<br><br> People who use it correctly:<br> get good results today.<br> may get either ugly results tomorrow, or good results tomorrow.<br> People who it wrongly:<br> get good results today.<br> get ugly results tomorrow.<br> More people will use it wrongly, since it's more complex.<br><br>So we trade cropped or visibly wrong results for ugly results, and good<br>results for possibly ugly results.<br> </blockquote><div><br>Well, "ugly" here actually means "visually just as good as today, but not as good as the results could be on a high-DPI device".<br> <br>Whereas "will get cropped or visibly wrong results tomorrow" could be so serious that browsers simply have to lock in to "ugly mode" forever to avoid them. Apparently I'm not the only one worried about that..</div></div></blockquote><div>WebKit already supports a high dpi canvas -- that's why i'm making as much noise about this as i am -- i'd like to implement it the best way possible, but without causing undue pain once this really starts mattering :D</div><br><blockquote type="cite"><div class="gmail_quote"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Maybe the least sucky option is to leave the API as-is, hope nothing bad happens, and if it does then we do what Oliver suggested and make getImageData downsample to ensure a 1:1 ratio, breaking the getImageData/putImageData invariant but oh well. Then later when the world is ready, introduce getImageDataReallyThisTime....</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>i was thinking having a style property, say, canvas-dpi: auto|device or something, where the default auto value automagically does the evil downsampling the moment a data routine is used, and device would result in the right thing. That said neither of these are particularly nice. OTOH it would allow those who use get/putImageData to implement a basic video buffer (eg. the msx demo, etc) to continue to do so.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite">(Alternatively: if the user is a Web developer, i.e. has Firebug installed, always make Gecko's canvas backing store 2 pixels per canvas unit! Just kidding. I think.)</blockquote><div>That's not actually a bad idea ;D</div><div><br class="webkit-block-placeholder"></div><div>Of course then people will probably complain that firebug makes canvas slow ;)</div><div><br class="webkit-block-placeholder"></div><div>--Oliver</div><br><blockquote type="cite"><br><br clear="all">Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]</blockquote></div><br></body></html>