- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Fri, 18 Oct 2013 16:25:18 +1300
- To: Glenn Maynard <glenn@zewt.org>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard <glenn@zewt.org> wrote: > "transferToImageBuffer" looks like it would create a new ImageBuffer for > each frame, so you'd need to add a close() method to make sure they don't > accumulate due to GC lag, > That's a good point. We will need something like that. It would only neuter that thread's (main thread or worker thread) version of the ImageBitmap. and it seems like turning this into a fast buffer swap under the hood would > be harder. > I don't see why. > Also, with the "transferToImageBuffer" approach, if you want to render > from a worker into multiple canvases in the UI thread, you have to post > those ImageBuffers over to the main thread each frame, which has the same > (potential) synchronization issues as the transferDrawingBufferToCanvas > proposal. > What are those issues? You can do a single postMessage passing a complete set of ImageBItmaps. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Received on Friday, 18 October 2013 03:25:43 UTC