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

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


Carrots and Sticks.

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
version that accomplishes the same thing, then they will just use that,
even if doing so causes their app to perform poorly.

See synchronous XMLHttpRequest.  I'm sure every browser vendor wishes that
didn't exist.  Note how we recently withdrew support for synchronous
ArrayBuffer access on XHR?  We did this precisely to discourage use of
synchronous mode XHR. Doing so actually broke some existing web pages.  The
pain was deemed worth it.

GPU readback of a HD buffer is going to suck.  Any use of this new API is
going to suck.

-Darin



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

Received on Monday, 16 April 2012 11:07:56 UTC