- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Thu, 19 Jun 2014 11:52:57 +1200
- To: Justin Novosad <junov@google.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, Stephen White <senorblanco@chromium.org>, WHAT Working Group <whatwg@whatwg.org>, Mark Callow <callow.mark@artspark.co.jp>, Dean Jackson <dino@apple.com>, Ian Hickson <ian@hixie.ch>
On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad <junov@google.com> wrote: > I am currently trying an experimental approach where canvases that are > drawn to, but never read from (no toDataURL or getImageData calls) have > their contents stored as a command buffer, rather than a pixel buffer. > There must be a cliff with that approach, where if you issue a sufficient number of drawing commands without clearing the canvas you have to rasterize, otherwise memory usage will grow without bound. That seems like a problem for authors. I think it's reasonably easy for authors to understand and control canvas memory usage at the moment, and I'd like to not make it worse. I can see that the command buffer approach would be useful for many applications though. 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 Wednesday, 18 June 2014 23:53:22 UTC