- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Thu, 19 Jun 2014 16:01:09 +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 11:52 AM, Robert O'Callahan <robert@ocallahan.org> wrote: > 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. > Also, you would have the problem of how correctly size temporary offscreen canvases and variable-resolution image assets that Ian's approach had. And without adding new API, there remains the problem of getImageData needing to return 1 pixel per canvas coordinate unit for compatibility, thus requiring some kind of getImageDataHD for authors who want more ... thus requiring new API. So while I applaud experimentation with retaining canvas command buffers, I don't want it to block consideration of alternatives for explicit canvas buffer sizing. 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 Thursday, 19 June 2014 04:01:51 UTC