- From: Elliott Sprehn <esprehn@chromium.org>
- Date: Wed, 15 Apr 2015 13:42:07 -0700
- To: Justin Novosad <junov@google.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, Kenneth Russell <kbr@google.com>, Stephen White <senorblanco@chromium.org>, WHAT Working Group <whatwg@whatwg.org>, Dean Jackson <dino@apple.com>, Ian Hickson <ian@hixie.ch>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Apr 15, 2015 at 12:07 PM, Justin Novosad <junov@google.com> wrote: > In the interest of moving forward with this, I began an experimental > implementation of the renderedPixelWidth/Height propsal ( > https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink. I ran > into > some issues, which I documented in the "issues" section of the proposal. I > would like to draw your attentions to them at this point: > > 1. Hard to determine a rendered size when the canvas is not attached to the > DOM. Perhaps in that case the current intrinsic size should be returned? > 2. After a layout change that affects rendered pixel size, there is no > guarantee that the size change event will be handled before the layout > change is propagated to screen, so the content may be temporarily displayed > in an inconsistent state. Note: the same issue exists with existing methods > that may be based on mutation observers or window.onresize, for example. > Though it is not the stated objective of this proposal to solve this > synchronization problem, there may be an opportunity to do so. > MutationObservers fire in the micro task, which is always before the next paint (actually before the next task). window.onresize runs at requestAnimationFrame time in Chrome which also means it never misses the next paint. 3. Accessing rendered pixel size is layout-inducing. To avoid layout > thrashing, we should consider making this an asynchronous getter (e.g. > asyncGetBoundignClientRect). This would also prevent renderedsizechanged > events from firing from within the evaluation of the > renderedPixelWidth/Height > attributes, which is weird. > renderedsizechanged feels like it's related to the general per element resize event problem. It'd be unfortunate to add an event to the browser specifically for canvas instead of solving the general problem. In that case authors will start resorting to hacks where they insert canvases into the page to listen for resizes (we've seen this with other events like overflowchanged). Perhaps we should add per element resize events and spec that they fire after the layout, but before the paint, during normal frame creation. That does mean you can cause an infinite loop if your resize handler keeps mutating the page, but there's so many other ways to cause that already. - E
Received on Wednesday, 15 April 2015 20:43:14 UTC