+1 from me too. But I have one concern in terms of future proofing, because
I would like to keep the door open for auto-resizing as a possible future
improvement. In an eventual auto-resize proposal, we will want to make
the "preferredsizechange"
event cancelable.  If we make the event non-cancelable initially, does that
lock us in forever in terms of spec backward compatibility? If the answer
is no, then +1 to Robert's proposal as is.

In terms of accommodating the possibility of auto-resizing with a command
buffer backed implementation, we should be able to add the necessary
signals for short-circuiting a full JS redraw by adding event attributes
and/or new event types on top of the current proposal.

On Thu, Jun 19, 2014 at 3:05 PM, Dean Jackson <d...@apple.com> wrote:

> > On 20 Jun 2014, at 12:54 am, Stephen White <senorbla...@chromium.org>
> wrote:
> >
> > On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan <
> rob...@ocallahan.org> wrote:
> > I think I'd rather not take control of canvas resizing away from
> applications, even opt-in. That leads to complexity such as extra API for
> slaving other canvases. I also think we'd be better off sticking to the
> invariant that the units of canvas coordinate space are single pixels in
> the canvas bitmap; I think that simplifies things for implementers and
> authors.
> >
> > I agree.
> +1 from me too.... and for the rest of Robert's proposal.
> Dean

Reply via email to