Re: [whatwg] High-density canvases

[Robert O'Callahan]

On Thu, Apr 16, 2015 at 7:07 AM, Justin Novosad ju...@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?


I think in this case you should estimate it based on the current zoom level
of the document, i.e. just assume no CSS transforms will be applied to the
element.


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


renderedsizechange isn't exactly the same as resize. For example during
zooming (any kind of zooming), an element with a fixed CSS px size does not
need to receive a resize event, but it should probably receive a
renderedsizechange.

I think we should keep renderedsizechange as a separate event, but we do
need to adjust how it fires. I think we should flush renderedsizechange
events before painting, just like we do for onscroll events.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Re: [whatwg] Fetch, MSE, and MIX

[Anne van Kesteren]

I removed some people from the cc. The WHATWG list seems to bite.

On Thu, Apr 16, 2015 at 6:57 PM, Ryan Sleevi sle...@google.com wrote:
 I think as we look to
 provide a compelling story for EME over wholly-proprietary (... rather than
 partially-proprietary) solutions, or look to improve the user experience in
 streaming video with MSE vs the video tag, this is still very much needed.

Okay, so accepting that for the moment, that leaves us with deciding
on the appropriate API on the MSE side. I don't have a strong
preference, but at this point MSE is the only case I can think of that
warrants an explicit opaque readable stream class. All the other use
cases I have (such as feeding img or script an arbitrary response)
would rather have a Response instance so headers and such are
preserved. And that Response can be opaque of course and then (as
currently specified) its .body would return null, but these privileged
contexts would get access to the underlying body stream.

I don't particularly mind introducing an opaque readable stream class,
but do we have any other use cases besides MSE?


-- 
https://annevankesteren.nl/