Feature proposal, not yet in spec: https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
rederedPixelWidth and rederedPixelHeight are read-only attributes that indicate the intrinsic size that must be set on a canvas for its pixels to map one-to-one to display device pixels. For applications that wish to render at the device's native resolution.
There is high demand for an API that guarantees one-to-one pixel alignment between
a canvas element and the display device. Current hacks that sniff the device pixel ratio tend to be inexact.
This feature does not interfere with any pre-existing functionality, and there is no immediate intent to ship.
Firefox has demonstrated public support for this feature (It's their proposal).
Ongoing technical constraints
There is currently some speculation about implementation issues related to interactions with layout (pixel coordinate snapping and the fact that the intrinsic size is in integers). An experimental implementation will allow us to explore these problems and possibly refine the feature proposal.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
OWP launch tracking bug?
Link to entry on the feature dashboard
Requesting approval to ship?
Can you point to examples of why "Current hacks that sniff the device pixel ratio tend to be inexact"? It would helpful to understand how this differs.
This seems like this would force a layout, right? In other threads, we have been talking about async versions of all layout-inducing apis, e.g. asyncGetBoundignClientRect so that you can get these things but eventually... that way you avoid layout thrashing.Should we be contemplating this here?
I see two issues here.* When applying a 3D tranform, the browser makes a choice as to the rendered resolution of the transformed layer (the layer backing), so the intrinsic size suggested by renderedPixelWidth and renderedPixelHeight should allow the canvas to match the resolution of the layer backing. I think image-rendering is orthogonal.
* There is a synchronization issue here because a compositor commit may get scheduled between a layout change and the invocation of the renderedsizechanged event handler, so we may end-up rendering a frame in an inconsistent state where the content has not been adapted to the new layout. That is a problem we already have today with code that relies on mutation observers or window.onresize. It is not a problem that this feature aims to fix, but if anyone has any ideas, please share. I don't think it is a good idea to postpone commits when there is a pending renderedsizechanged event, because that could lock-up the main thread if the event handler touches layout.