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

> If part of paint needs to run, it's a tough pill to swallow to duplicate that work, which is why a frame of latency allowance helps.

Chromium's implementation does not duplicate any work. There is a pre-paint rendering lifecycle
phase that is after layout and before paint, and among other things computes paint offset.

> 
> Canvas _cannot possibly_ stay 1-1 throughout a CSS Animation, so we know we're already working on an imperfect solution.

A CSS animation for anything other than transform or opacity induces layout as necessary, which runs the ResizeObserver on every frame. Transforms, as mentioned by Ken above, are not taken into account for the device-pixel-border-box, and so is not a problem. Transform animations without layout/ResizeObserver is one motivating reason for this rule, in addition to the ones Ken mentioned.

> 
> Ideally, a pre-snapped rect will be exactly N pixels tall regardless of offset, unless we round the edge y0 and y1, instead of y0 and height. Anything else will require spurious resizes, which not only do we not want in webgl, but we don't want in general web content painting. Is my intuition leading me astray here?

Suppose you have a canvas inside of a div of exactly the same CSS pixel size. The border of the div should match up exactly to the edge of the canvas. For this reason, the div and canvas have to have the same rounding algorithm.

As for why the rounding needs to depend on position: consider two sibling divs that have fractional widths and paint offsets and need to touch each other with no gap. In this case the rounding needs to be consistent, and the way to achieve that is to include subpixel accumulation (which in turn depends on fractional paint offset) in the rounding, so that they round the same direction. This is why the rounding depends on paint offset.

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

Received on Tuesday, 21 May 2019 20:48:25 UTC