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.

- James
On Mar 20, 2012 10:29 AM, "Edward O&apos;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
>

Reply via email to