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

[Darin Fisher]

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

>
> On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote:
>
> On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt <oliver at apple.com> wrote:
>>
>> I don't understand why adding a runloop cycle to any read seems like
>> something that would introduce a much more noticable delay than a memcopy.
>>
>
> The use case is deferred rendering.  Canvas drawing calls don't need to
> complete synchronously (before the drawing call returns); they can be
> queued, so API calls return immediately and the actual draws can happen in
> a thread or on the GPU.  This is exactly like OpenGL's pipelining model
> (and might well be implemented using it, on some platforms).
>
> The problem is that if you have a bunch of that work pipelined, and you
> perform a synchronous readback, you have to flush the queue.  In OpenGL
> terms, you have to call glFinish().  That might take long enough to cause a
> visible UI hitch.  By making the readback asynchronous, you can defer the
> actual operation until the operations before it have been completed, so you
> avoid any such blocking in the UI thread.
>
>
>>  I also don't understand what makes reading from the GPU so expensive
>> that adding a runloop cycle is necessary for good perf, but it's
>> unnecessary for a write.
>>
>
> It has nothing to do with how expensive the GPU read is, and everything to
> do with the need to flush the pipeline.  Writes don't need to do this; they
> simply queue, like any other drawing operation.
>
>
> 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?
>
>
I think it would not need to.  It would just return a snapshot of the state
of the canvas up to the point where the asyncGetImageData call was made.
 This makes sense if you consider both draw calls and asyncGetImageData
calls being put on the same work queue (without any change in their
respective order).

-Darin