- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 16 Apr 2012 17:10:52 -0500
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
Received on Monday, 16 April 2012 15:10:52 UTC