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