[css-houdini-drafts] [css-paint-api] Calls to paint function should provide the snapped concrete size.

flackr has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [css-paint-api] Calls to paint function should provide the snapped concrete size. ==
[Section 8: Drawing an image](https://drafts.css-houdini.org/css-paint-api-1/#drawing-an-image) specifies that the Concrete Object Size is used when invoking the paint callback, however in the case of subpixel sizes the actual paint size depends on the browser's subpixel snapping.

For [example](http://jsbin.com/xoteqif/edit?html,js,output), given a device with a scale factor of 1.25 if drawing a series of boxes of size 9px, the physical screen size is 11.25px. This means that one in every 4 boxes will be drawn a physical pixel taller than the rest.

There are 4 options I can think of although I believe we should avoid the first two as neither allows developers to do the right thing:
1) Don't change spec, causing all paintings to be blurry (scaled up or down to fit pixel snapping).
2) Don't change spec, draw at subpixel position causing paintings to be blurry.
3) Adjust concrete object size to be snapped size / devicePixelRatio (e.g. in this example pass in either 11 / 1.25 = 8.8px or 12 / 1.25 = 9.6px). Edges of the drawn object size continue to be sharp and developers scaling by devicePixelRatio and accounting for the object size get pixel perfect drawings.
4) Add backingStorePixelRatio(X|Y) which maps concrete size to physical pixel size.

My preference is for option 3 given it is a small change, and it produces crisp edges for developers naively painting to their size, and do the right thing for developers taking into account the devicePixelRatio as well.

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/508 using your GitHub account

Received on Tuesday, 7 November 2017 01:32:52 UTC