- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Dec 2019 18:15:12 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Resize-Observer
---------------
- There is a need for test cases in order to determine the possible
implications of adding two APIs to get the device pixel box size
(Issue #3554: ResizeObserver device-pixel-border-box size) since
this is handled differently on different OSes.
- Once there are test cases the group will look at this topic again
and decide if either the cases work in all OSes or if it's still
better to have an API that returns an approximation in some OSes
vs no API at all.
===== FULL MINUTES BELOW =======
Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda
Scribe: fantasai
Resize-Observer
===============
ResizeObserver device-pixel-border-box size
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3554
chrishtr: device-pixel-border-box is the actual device pixel bounds
of a canvas element
chrishtr: Including pixel-snapping feature which is used by browsers
to avoid blurriness by snapping to pixel grid
chrishtr: fundamental problem with no complete solution
chrishtr: Authors that use canvas
chrishtr: have no reliable method to determine on-screen pixel size
of the canvas
chrishtr: If off by one pixel due to pixel-snapping, rounding, or
other issue
chrishtr: will end up with wrong or blurry results
chrishtr: pixel-snapping is intentionally not specced to allow UAs
to do their best
chrishtr: account for varying rendering architecture
chrishtr: and evolution
chrishtr: so no way to reliably find this size
chrishtr: Proposal is to add a box that observes device pixel border
box
chrishtr: to ResizeObserver
chrishtr: which will notify if that box changes
chrishtr: Will happen at similar timing as other ResizeObserver
chrishtr: There were two main objections to adding this
chrishtr: One was raised by Jeff Gilbert
chrishtr: Had a long discussion with him and Ken Russell, our WebGL
expert
chrishtr: have a compromise proposal that both of us agree to
chrishtr: Objection he raised was that if you have a WebGL-centric
application
chrishtr: e.g. full-screen game that uses WebAssembly and only DOM
in minimal way
chrishtr: Want to have a continuous requestAnimationFrame loop
chrishtr: drawing the canvas
chrishtr: in that model where you are canvas-centric
chrishtr: It still lives in a DOM shell or browser window that has a
size
chrishtr: Need to observe that size
chrishtr: where pixel snapping will work
chrishtr: but in Web Assembly not in JS
chrishtr: Most convenient to query device border box directly from
canvas during rAF loop
chrishtr: rather than by observer
chrishtr: If layout was dirty at the time during making the query,
it will force layout and other things in order to compute
pixel snapping
chrishtr: in that use case maybe it's OK
chrishtr: Other use case, which I was most focused on
chrishtr: You have canvas element embedded in a DOM-centric website
chrishtr: maybe photo-app or ad or widget,
chrishtr: potential multi-actor scenario
chrishtr: Want to avoid layout thrashing
chrishtr: cases for which ResizeObserver was designed
chrishtr: this makes most sense
chrishtr: Compromise proposal is that we just have both APIs
jgilbert: ... Moving forward with both proposals works out
jgilbert: having it be in ResizeObserver also makes sense
jgilbert: Like you went over, there was some concerns about it
covering especially more easily some more trivial cases
jgilbert: having both lets people pick and choose appropriate API
jgilbert: Default should be to use ResizeObserver, most reliable
jgilbert: kindof like getClientBoundingRect() , need to be careful
if calling that often
jgilbert: maybe warn in UA
jgilbert: if called too often
jgilbert: but getDeviceClientRect() API alone ...
chrishtr: 2nd objection smfr raised
chrishtr: pixel-snapping requires more information than just layout
in today's engines
chrishtr: In Chrome requires pre-paint step
chrishtr: In Safari requires paint
chrishtr: don't have solution to that problem
chrishtr: Just note readback method for rAF
chrishtr: canvas.getThing
chrishtr: Also has to run the same steps
Rossen: But that's not blocking to accept the proposal
smfr: In some ways makes it worse
smfr: because 2 places we have to do this painting calculation
Rossen: Was asking if this second objection is blocking accepting
the proposal
smfr: So to clarify the proposal is having API to return the box on
canvas and also in ResizeObserver
smfr: I'm not a fan of doing partial paints to get this info
smfr: I would expect for games , especially in full-screen, to
position on ? boundaries
smfr: Surprised if using fractional pixel positioning
jgilbert: For full-screen, unlikely, but for partial screen almost
always get this
jgilbert: both on Windows and on Android, I believe, Windows will
happily give you 1.6574 device pixel ratio
jgilbert: you just have to deal with it
jgilbert: You end up trying to reverse-engineer what pixel-snapping
is to figure that out
jgilbert: pre-snap a rect to a non-integer CSS size, if that works
out to integer pixels... then no artifacts? but it's a
huge mess
smfr: Other case that's confusing is on our iPhone's that have
retina displays
smfr: already 2.7? scaling factors
smfr: so can cause hairlines to disappear etc.
smfr: Seems like also on windows, too
smfr: Getting pixel perfection, seems like OS is doing scaling
behind your back, how can you expect it to work?
jgilbert: Out of the box cases where if you play around with virtual
scaling
jgilbert: on a Mac and play with scaling on a retina screen
jgilbert: no way to get 1-1 device pixel
myles: Even worse, the default ratio is not 1-1 or 2-1
jgilbert: It really depends on how the OS is doing this sort of
scaling
jgilbert: I'll add that what you end up with, for instance in Mac,
when you have this OS-level virtual resolution scaling
jgilbert: Can't get one to one
jgilbert: If can't get 1-1 in application, can still get moire
effects
jgilbert: Can't entirely eliminate scaling artifacts, but can do
better
jgilbert: than naively try to grid on the screen and hope it looks
good
mattwoodrow: Difference is on Windows the scaling isn't hidden
mattwoodrow: can attempt to match
jgilbert: Windows 10 implements scaling that allows 1-1 rendering,
not virtual scaling as default
jgilbert: Mac doesn't expose effective scaling, just says 2x all the
time
jgilbert: Android says 3x all the time
mstange: Regardless of what operating systems do, if application
renders pixel-perfect
mstange: Result will be better than if it wasn't
mstange: I think we agree on that
myles: If goal is to get hairlines, even if you get a little closer
to hairline, can still disappear
mstange: Display scaling might give you smoother color if
checkerboard is pixel-perfect before the scaling
mstange: and if you have checkerboard before scaling, then less
smooth design
mstange: Still discussing value of getting an accurate box? what's
status?
jgilbert: If we decide that we don't want to give ppl this box, then?
jgilbert: Do we want to get into that? or do we want to take it as a
given that we're trying to give ppl most correct idea of
device pixel than we can?
mstange: What we would need to do in Firefox to get this result
mstange: Firefox takes into account the full zoom, and takes into
account CSS Transforms
mstange: space in which we snap is established by the closest
animated transform or the root
mstange: We only know this info during painting
mstange: so would need to run more steps before giving info
smfr: This device border box would not be affected by transforms
smfr: so would have to do *special* calculation
jgilbert: 3D transforms no idea what to feed back
jgilbert: pixel-snapped bounding box?
atotic: If you're doing transforms won't be pixel-perfect anyway, so
don't worry about it
atotic: You're also talking about implementation that you need to
get this information during pre-painting
atotic: remember you had this information ??
atotic: Might be ok to deliver incorrect information and not have to
paint
myles: There's a chance of you never get correct info
atotic: I think you want, once things have settled down want
accurate box size
atotic: if animating, don't care so much
jgilbert: Deliver information lately
jgilbert: Would be nice if we could try so that you could do 1-1
perfect every time within certain set of constraints
jgilbert: Be nice if we didn't immediately settle on a 1 frame late
policy
jgilbert: matching what native APIs are able to do
jgilbert: Don't want to suffer if don't have to suffer on native
myles: If it is one frame late then the exact timeline that we drop
frames is exposed to the Web so don't think we want that
myles: Similarly, worried that we'd have to reverse-engineer
chrome's pixel-snapping strategy
jgilbert: Shouldn't have to do more normalization than you do today,
I think
jgilbert: If trying to use this to get anti-moire, in order to do
this today have to ??
smfr: One frame late version also problem of which rectangle to trust
chrishtr: Not late if layout occurred
chrishtr: only late if you have a threaded animation
smfr: Thought it would be late because we would collect info at
paint time
chrishtr: I don't think we should do that, disagree with atotic
chrishtr: Think we can do it therefore we should
chrishtr: in cases where layout has occurred
chrishtr: Agree with point about threaded animations and not syncing
with JS thread
smfr: Want to tie together two of previous points, first that if we
implement this paint day device pixel border box, will be more
expensive for us
smfr: secondly because of physical mismatch, wouldn't have some user
benefit
smfr: display is scaling anyway
smfr: Can we get examples?
smfr: Want to try on Apple devices, see what would happen if looks
right
atotic: Moire pattern
atotic: If you're moving canvas around the screen, the moire is
animated. looks really bad
smfr: Please give us some tests
chrishtr: I think time is up?
chrishtr: Propose to add the feature?
Rossen: Does the group feel there's enough merit to add this?
Rossen: Would be adding both APIs
Rossen: Is there any objection?
smfr: I don't think we can accept new API without evidence that it's
so much better that it's worth the extra cost
fremy: You can agree with the API and just return some approximate
result if you feel it's good enough
myles: You're saying implement the API without implementing the API
fremy: Might not be useful on your device
fremy: but might be useful on Android
fremy: so just return the result
AmeliaBR: Not having an API is better than having API with bad
results
AmeliaBR: If a particular browser has particular concerns about
implementing the particular API
fantasai: In this case it would be, if you as an author were trying
to do this thing, and you had this browser gives me the
actual DPR, and this one gives me some approximation of
the size
fantasai: I still need to size my box either way
fantasai: If my choice is I can get the actual device pixel size
from Chrome, but calculate it myself from width/height
props in WebKit, and get an approx result, then I don't
know, it might be better to have an API that does that
calculation for me
fantasai: then I only need to write one code flow
AmeliaBR: Might make sense, but have existing cases where you can't
trust the API
florian: In general I agree with your statement, this doesn't seem
to be such a case
Rossen: I would like to end this topic
Rossen: Going to call for objections to adding the API, if we have
objections we'll deal with them and have additional
conversations with the TAG and whatnot
Rossen: Any objections to having these APIs?
smfr: Can we wait until we have the examples?
astearns: I might object because seems like we need more data
astearns: So I will object on Safari's behalf
Rossen: So back to you to get test cases, we'll discuss again on
telecon
Received on Tuesday, 3 December 2019 23:16:07 UTC