[whatwg] More random comments on the putImageData definition

Oliver Hunt oliver at apple.com
Sun Feb 10 16:05:02 PST 2008


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-0001.htm>


More information about the whatwg mailing list