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.
Neat idea to offer async backing store access. I'm not sure that we should tie
this to backing store access at true backing store resolution vs at CSS pixel
nominal resolution, because it will significantly raise the barrier to authors
recoding their existing apps to take full advantage of higher resolutions. With
Ted's proposal, all they would have to do is use the HD versions of calls and
change their loops to read the bounds from the ImageData object instead of
assuming. If we also forced the new calls to be async, then more extensive
changes would be required.
I hear you on the benefits of async calls, but I think it would be better to
sell authors on their benefits separately.
Cheers,
Maciej
>
> - James
> On Mar 20, 2012 10:29 AM, "Edward O'Connor" <eocon...@apple.com> wrote:
>
>> Hi,
>>
>> Unfortunately, lots of <canvas> content (especially content which calls
>> {create,get,put}ImageData methods) assumes that the <canvas>'s backing
>> store pixels correspond 1:1 to CSS pixels, even though the spec has been
>> written to allow for the backing store to be at a different scale
>> factor.
>>
>> Especially problematic is that developers have to round trip image data
>> through a <canvas> in order to detect that a different scale factor is
>> being used.
>>
>> I'd like to propose the addition of a backingStorePixelRatio property to
>> the 2D context object. Just as window.devicePixelRatio expresses the
>> ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would
>> express the ratio of backing store pixels to CSS pixels. This allows
>> developers to easily branch to handle different backing store scale
>> factors.
>>
>> Additionally, I think the existing {create,get,put}ImageData API needs
>> to be defined to be in terms of CSS pixels, since that's what existing
>> content assumes. I propose the addition of a new set of methods for
>> working directly with backing store image data. (New methods are easier
>> to feature detect than adding optional arguments to the existing
>> methods.) At the moment I'm calling these {create,get,put}ImageDataHD,
>> but I'm not wedded to the names. (Nor do I want to bikeshed them.)
>>
>>
>> Thanks for your consideration,
>> Ted
>>
