W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2012

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

From: Darin Fisher <darin@chromium.org>
Date: Mon, 16 Apr 2012 14:00:46 -0700
Message-ID: <CAP0-Qpsu3Ys51QWy0UY=g5DF1_7me7JeBmRAue+=1o7A6z8-5A@mail.gmail.com>
On Mon, Apr 16, 2012 at 1:45 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Apr 16, 2012, at 11:07 AM, Darin Fisher <darin at chromium.org> wrote:
> >
> > 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.
>
> Yes, but the reason for this is very simple: synchronous IO can take a
> literally interminable amount of time, in which nothing else can happen.
>  We're talking about something entirely client side, that is theoretically
> going to be done sufficiently quickly to update a frame.
>
> The IO case has a best case of hundreds of milliseconds, whereas that is
> likely to be close to the worst case on the graphics side.
>
>
Sorry, I did not make my point clear.  I did not intend to equate network
delays to graphics delays, as they are obviously not on the same order of
magnitude.  Let me try again.

We decided that we didn't like synchronous XHR.  We decided to withhold new
features from synchronous XHR.  I believe we did so in part to discourage
use of synchronous XHR and encourage use of asynchronous XHR.

I was suggesting that we have an opportunity to apply a similar approach to
canvas ImageData.

I have learned that it is not commonly accepted that reading ImageData can
be slow.  I had assumed otherwise.

-Darin
Received on Monday, 16 April 2012 14:00:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:07 GMT