Re: [whatwg] Canvas image to blob/dataurl within Worker
On Tue, Apr 14, 2015 at 10:53 PM, Robert O'Callahan rob...@ocallahan.org wrote: I guess there are really two different sets of use-cases: 1) Use-cases where the ImageBitmap is sized to fill a particular area of the screen. 2) Use-cases where the ImageBitmap is sized subject to some other constraints, e.g. you're processing an existing image. For #2, you want the ImageBitmap's size to be the intrinsic size of the element. For #1, you don't care about having an intrinsic size. Instead the element's size is set by CSS and you want the ImageBitmap to fill the element, and you want to be able to use renderedPixelWidth/Height to size the ImageBitmap. However, for these use-cases I think the behavior currently specced in the OffscreenBitmap proposal doesn't make sense: // The ImageBitmap, when displayed, is clipped to the rectangle // defined by the canvas's instrinsic width and height. Pixels that // would be covered by the canvas's bitmap which are not covered by // the supplied ImageBitmap are rendered transparent black. I'm not sure what this means now. Suppose the canvas element has CSS width:100px; height:100px and the canvas rendered size is 200x200. If the application creates a 200x200 ImageBitmap and installs it in the canvas, as specced isn't this just going to display some 100x100 subrectangle of the ImageBitmap, cropping out the rest? I believe this is *intending* to say that ImageBitmap is just spammed into a canvas directly, matching pixels 1-to-1. If the ImageBitmap overflows the canvas in some dimension, the extra is discarded; if it underflows, the underflow is painted transparent black. CSS has no effect on this. This needs to be stated more explicitly, of course. The idea is that this isn't drawing an image into the canvas, it's like loading an ImageData. What if instead of a new context type, we had a method on the canvas element itself to install a new ImageBitmap, which replaces the backbuffer and sets the intrinsic size of the canvas element to the ImageBitmap's size, so that 'width' and 'height' are thereafter ignored? Then if the canvas has non-auto CSS 'width' and 'height', the image buffer will be scaled to fit the CSS size and the example above will work as expected. CSS object-fit will then also work, so if the ImageBitmap producer lags behind canvas resizing for some reason, authors can use object-fit:contain (or cover) to display the mis-sized images in a reasonable way. (object-fit is also important for the case where a Worker is presenting images through an OffscreenCanvas and its image production may lag behind resizing of the canvas element on another thread; we can pass the object-fit value through to the compositor to ensure the temporary results look OK.) This works for me; it avoids the author having to coordinate between scripts and predict the size of the image beforehand. ~TJ
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
I think the original approach of adding a fourth argument is much better. It's also a better API in general, since the URL should always be given. If we had a one-argument form with a dictionary, people would consider not giving the URL but just disabling scrolling, which is suboptimal. You can require arguments with dictionaries. Actually URL is optional in current spec and it defaults to current URL. Why is this suboptimal? In anycase If making URL required is a goal then it is best done by introducing a new method to avoid breaking compatibility. I personally find a dictionary with only optional members which have appropriate defaults to be very convenient. Here are some reasonable defaults: - url: current URL - title: current title - state: null - restoreScroll: true (or willRestoreScrollPosition: false)
Re: [whatwg] High-density canvases
On Wed, Apr 15, 2015 at 12:07 PM, 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? 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
Re: [whatwg] High-density canvases
On 16 Apr 2015, at 6:42 am, Elliott Sprehn espr...@chromium.org wrote: 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. +1 Dean
Re: [whatwg] High-density canvases
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. 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.
Re: [whatwg] High-density canvases
On Wed, Apr 15, 2015 at 1:46 PM, Dean Jackson d...@apple.com wrote: On 16 Apr 2015, at 6:42 am, Elliott Sprehn espr...@chromium.org wrote: 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. +1 If that's a viable option let's do that. It would solve many longstanding problems. -Ken
Re: [whatwg] Fetch, MSE, and MIX
On Wed, Apr 15, 2015 at 6:45 PM, Martin Thomson martin.thom...@gmail.com wrote: I believe that the easiest way to avoid this is to make an attempt to read Response.body raise a SecurityError if the origin is different (in Firefox terms, we would say if the response principal is not subsumed by the script principal). The proposal is that .body returns an opaque stream object that you cannot read from, but privileged code can. But yes, same general idea as the SOP dances elsewhere. Having said all this, it has come to my attention that Netflix had a change of heart so maybe we do not want to put effort into this new Mixed Content API? It could still be useful for same-scheme-cross-origin-no-cors of course, but nobody has asked for that. -- https://annevankesteren.nl/
