[whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

Charles Pritchard chuck at jumis.com
Mon Apr 16 11:18:51 PDT 2012

On 4/16/2012 11:07 AM, Darin Fisher wrote:
> On Wed, Mar 21, 2012 at 8:29 PM, Maciej Stachowiak<mjs at apple.com>  wrote:
>> On Mar 20, 2012, at 12:00 PM, James Robinson wrote:
>>> If we are adding new APIs for manipulating the backing directly, can we
>>> make them asynchronous? This would allow for many optimization
>>> opportunities that are currently difficult or impossible.
>> I hear you on the benefits of async calls, but I think it would be better
>> to sell authors on their benefits separately.
> Aren't we missing an opportunity here?  By giving web developers this easy
> migration path, you're also giving up the opportunity to encourage them to
> use a better API.  Asynchronous APIs are harder to use, and that's why we
> need to encourage their adoption.  If you just give people a synchronous
> GPU readback of a HD buffer is going to suck.  Any use of this new API is
> going to suck.

The vibe I got from the discussion over at WHATWG is that developers and 
vendors would like to see an async getImageDataHD.
"put" isn't so much of an issue, but "get" is.

As developers, we're going to be using async more-and-more with Canvas; 
from the toBlob semantic to postMessage transfer semantics.
As a Canvas developer, I'd be inclined to use the HD buffer even if it's 
the same backing size as the standard buffer, if it supported async 


Separately, I'm hoping to see this issue sorted out:

IE9+: magicNumber = window.screen.deviceXDPI / window.screen.logicalXDPI;
WebKit: magicNumber = (window.outerWidth / window.innerWidth) * 
(window.devicePixelRatio||1) ; 'with a small margin of error';

Canvas developers today need to use that nasty webkit hack to get their 
magic number. It's not fun, and I wish we could move off it.
IE9 on the desktop works appropriately. I can use browser zoom and 
re-render with a crisp/sharp Canvas bitmap using the window.screen 


More information about the whatwg mailing list