Re: [whatwg] High-density canvases

On Thu, Jun 19, 2014 at 12:01 AM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> 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.
>>
>
Yes there needs to be a threshold where the command buffer gets flushed and
discarded. We ran into that problem already with the deferred rasterization
mechanism already shipping in Chrome. Right now, it is not a big deal
because canvases are not auto-resized. With auto-resizing enabled, flushing
the command buffer will mean locking in a resolution.


> 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.
>

Or the command buffer could be played back into a temporary buffer with 1:1
canvas pixel ratio.  But that is not ideal either, because there would be
loss of resolution through a getImageData/putImageData round trip.


> 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.
>

I agree, the more I think about and discuss this with others, the clearer
it seems that auto-resizing needs to be explicitly controlled and opt-in
behavior because the are too many problematic edge cases that would regress
existing usage.  That being said, the concept of retaining a command
buffer, but without the auto-resizing behavior, is still beneficial and can
be implemented without changes to the spec. Once we add an new HD API, the
command buffer implementation will not be a requirement, but may be quite
useful for providing an efficient resizing implementation.  With that in
mind, I would like us to make sure that any new HD canvas API could
accommodate such an implementation.

Looking at your proposal, the "preferredsizechange" event is the tricky
part. That event would be used as a signal to resize and  redraw canvas
contents for web pages that choose to resize their canvases dynamically.
However, if the browser is in a state where it is able to redraw the canvas
contents from a command buffer, then we may not want to redraw contents in
JavaScript and delegate the resize work to the browser. In that case, we
still need to let the web application know that the preferred size has
changed, just in case the application needs that information to do
something special. For example, when resizing beyond a certain threshold,
the app may decide to redraw in JS anyways in order to switch to assets
(like sprites) of a different resolution.

    -Justin

Received on Thursday, 19 June 2014 14:10:58 UTC