Re: [csswg-drafts] [resize-observer] device-pixel-border-box size (#3554)

> It should be sufficient for ResizeObserver to be eventually consistent, so a frame of latency would be acceptable, though it sounds like the spec doesn't presently allow this behavior.

Re "a frame of latency would be acceptable": are you saying you think that it's ok for the canvas to draw wrong for one frame and then fix itself? If so, I don't agree. Fixing this is the point of ResizeObserver after all..

> 
> FWIW, I'm playing with a pixel-pre-snapping resize: `canvas.style.width = canvas.width / window.devicePixelRatio`, which appears to work well on at least Windows. It does, of course, depend on an assumed pixel snapping behavior, which may be insufficient to work on all platforms. (But theoretically, the behavior seems sound for intuitive pixel snapping)

This does not work, because pixel snapping on browsers takes into account position as well as device pixel size. This is necessary in order to have consistent and high-quality rendering when a canvas is contained within layout boxes, and between layout phases of a box. Subpixel layout and pixel snapping are necessary and inherent parts of high-quality DOM rendering.

> 
> device-pixel-border-box does satisfy this use-case, but it seems incredibly specific. Perhaps it needs to be because of layout rules I'm not familiar with, but @dholbert indicated that this should work in at least some cases. I'm following up with our Painting/Compositing people.

I don't think this is incredibly specific at all. The reason canvas is special is that it's an immediate-model API that draws directly to a backing, as opposed to CSS+HTML rendering, which is mediated by the browser. Therefore the canvas needs to know exactly how big the backing is.

However, the canvas is not rendered in isolation, but rather is an immediate-mode rendering contained *within* a browser-mediated DOM that has subpixel rendering, pixel snapping, and render timing that is UA-controlled. For this reason, the developer needs a way for the canvas to participate in the rendering lifecycle, via an appropriate callback once the size of the canvas backing is known. The correct timing of this is once layout is complete and before/during paint.

This is very similar to the basic ResizeObserver use-case, except that the canvas needs to also observe the pixel snapping inputs to paint. Therefore, as Simon mentioned, "part of" paint needs to run, in order to compute paint offset, which is an input to the pixel snapping algorithm. I agree that this  is more work, but it's necessary for high-quality rendering, and is not *that* hard to implement. 

-- 
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-494471746 using your GitHub account

Received on Tuesday, 21 May 2019 16:52:21 UTC