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

[Glenn Maynard]

On Mon, Apr 16, 2012 at 2:18 PM, Oliver Hunt <oliver at apple.com> wrote:

> Could someone construct a demonstration of where the read back of the
> imagedata takes longer than a runloop cycle?
>

"Runloop" doesn't mean anything to me (nor to Google [1], nor to the HTML
specification).  If you're talking about WebKit-specific limitations,
please explain what you're talking about (most of us aren't WebKit
developers).

If you make an asynchronous call, the call should execute as soon as
possible after returning to the event loop; if there are no other jobs on
that task queue or other drawing operations pending, then it should happen
with a near-zero delay.  Where this doesn't happen in practice, it's
something that should be fixed. (That would cause problems with many other
async APIs.  For example, if you perform an asynchronous File API read, and
that read has an additional 2ms delay, then sequentially reading a file 64k
at a time would cap out at 32MB/sec.  It should only artificially delay
event queue tasks if it's actually necessary for UI responsiveness.)


[1] https://www.google.com/#sclient=psy-ab&hl=en&q=site:w3.org+%22runloop%22



On Mon, Apr 16, 2012 at 3:45 PM, Oliver Hunt <oliver at apple.com> wrote:

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

(Actually, the best case should be almost instantaneous, if you're using
XHR to read from an object URL that points to a Blob stored or cached in
RAM, or for network requests that can be served out of network cache.
 You're correct in the more common cases, of course, though I'd say the
best case for network requests is in the tens of milliseconds, not
hundreds.)


On Mon, Apr 16, 2012 at 4:06 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> Would the async version still require a flush and immediate readback if
> you do any drawing after the get call but before the data is returned?
>

So long as the implementation handles all drawing calls asynchronously, no.
 The later drawing operations will simply be queued to happen after the
completion of the readback.

If the implementation can do some things async and some not, then it may
still have to block.  That's just QoA, of course: this is meant to allow
implementations to queue as much as possible, not to require that they do.

--
Glenn Maynard