- From: Oliver Hunt <oliver@apple.com>
- Date: Sun, 10 Feb 2008 16:05:02 -0800
On Feb 10, 2008, at 3:08 PM, Robert O'Callahan wrote: > On Feb 11, 2008 11:49 AM, Ian Hickson <ian at hixie.ch> wrote: > If we have one API, high-res only: > > People who use it correctly: > get good results both today and tomorrow. > People who use it wrongly: > get good results today. > will get cropped or visibly wrong results tomorrow. > > If we have two APIs: > > People who use it correctly: > get good results today. > may get either ugly results tomorrow, or good results tomorrow. > People who it wrongly: > get good results today. > get ugly results tomorrow. > More people will use it wrongly, since it's more complex. > > So we trade cropped or visibly wrong results for ugly results, and > good > results for possibly ugly results. > > 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". > > 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.. 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 > 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.... 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. > (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.) That's not actually a bad idea ;D Of course then people will probably complain that firebug makes canvas slow ;) --Oliver > > > Rob > -- > "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] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080210/44255d0f/attachment.htm>
Received on Sunday, 10 February 2008 16:05:02 UTC