W3C home > Mailing lists > Public > www-style@w3.org > December 2019

[CSSWG] Minutes Fukuoka F2F 2019-09-17 Part V: Resize-Observer [resize-observer]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 3 Dec 2019 18:15:12 -0500
Message-ID: <CADhPm3vyDi+t0zmUxEt7dpctVdu0VjQUbwO42zNnTWfwewsvUw@mail.gmail.com>
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.


  - 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


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
  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
  chrishtr: have a compromise proposal that both of us agree to

  chrishtr: Objection he raised was that if you have a WebGL-centric
  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
  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
  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
  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
  jgilbert: Can't entirely eliminate scaling artifacts, but can do
  jgilbert: than naively try to grid on the screen and hope it looks
  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
  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
  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
  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
  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
  smfr: display is scaling anyway
  smfr: Can we get examples?
  smfr: Want to try on Apple devices, see what would happen if looks
  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
  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
Received on Tuesday, 3 December 2019 23:16:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:14 UTC