On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote: > On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt <oli...@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? Regards, Maciej
