- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Sep 2019 05:36:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `ResizeObserver Device Pixel Border Box`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: ResizeObserver Device Pixel Border Box<br> <fantasai> ScribeNick: fantasai<br> <fantasai> chrishtr: device-pixel-border-box is the actual device pixel bounds of a canvas element<br> <fantasai> chrishtr: including pixel-snapping feature which is ued by browsers to avoid blurriness by snapping to pixel grid<br> <fantasai> chrishtr: fundamental problem with no complete solution<br> <fantasai> chrishtr: authors that use canvas<br> <fantasai> chrishtr: have no reliable method to determine on-screen pixel size of the canvase<br> <fantasai> chrishtr: if off by one pixel due to pixel-snapping, rounding, or other issue<br> <fantasai> chrishtr: will end up with wrong or blurry results<br> <fantasai> chrishtr: pixel-snapping is intentionally not specced to allow UAs to do their best<br> <fantasai> chrishtr: acocunt for varying rendering architecture<br> <fantasai> chrishtr: and evolution<br> <fantasai> chrishtr: so no way to reliably find this size<br> <fantasai> chrishtr: proposal is to add a box that observes device pixel border box<br> <fantasai> chrishtr: to ResizeObserver<br> <fantasai> chrishtr: which will notify if that box changes<br> <fantasai> chrishtr: will happen at similar timing as other ResizeObserver<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3554<br> <fantasai> chrishtr: there were two main objections to adding this<br> <fantasai> chrishtr: one was raised by Jeff Gilbert<br> <fantasai> chrishtr: had a long discussion with him and Kem Russel, our WebGL expert (?)<br> <fantasai> chrishtr: have a compromise proposal that both of us agree to<br> <heycam> s/Kem Russel/Ken Russell/<br> <fantasai> chrishtr: objection he raised was that if you have a WebGL-centric application<br> <fantasai> chrishtr: e.g. full-screen game that uses WebAssembly and only DOM in minimal way<br> <fantasai> chrishtr: want to have a continuous requestAnimationFrame loop<br> <fantasai> chrishtr: drawing the canvas<br> <fantasai> chrishtr: in that model where you are canvas-centric<br> <fantasai> chrishtr: it still lives in a DOM shell or browser window that has a size<br> <fantasai> chrishtr: need to observe that size<br> <fantasai> chrishtr: where pixel snapping will work<br> <fantasai> chrishtr: but ... not in JS<br> <heycam> s/.../in Web Assembly/<br> <fantasai> chrishtr: most convenient to query device border box directly from canvas during rAF loop<br> <fantasai> chrishtr: rather than by observer<br> <fantasai> 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<br> <fantasai> chrishtr: in taht use case maybe it's OK<br> <fantasai> chrishtr: other use case, which I was most focused on<br> <fantasai> chrishtr: you have canvas element embedded in a DOM-centric website<br> <fantasai> chrishtr: maybe photo-app or ad or widget,<br> <fantasai> chrishtr: potential multi-actor scenario<br> <fantasai> chrishtr: want to avoid layout thrashing<br> <fantasai> chrishtr: cases for which ResizeObserver was designed<br> <fantasai> chrishtr: this makes most sense<br> <fantasai> chrishtr: compromise proposal is that we just have both APIs<br> <fantasai> chrishtr: The End! :D<br> <fantasai> jeff: ....<br> <fantasai> jgilbert: ... moving forward with both propsoals works out<br> <fantasai> jgilbert: having it be in ResizeObserver also makes sense<br> <fantasai> jgilbert: like you went over, there was some concerns about it covering espeically more easily some more trivial cases<br> <fantasai> jgilbert: having both lets people pick and choose appropriate API<br> <fantasai> jgilbert: default should be to use ResizeObserver, most reliable<br> <fantasai> jgilbert: kindof like getClientBOundingRect() , need to be careful if calling that often<br> <fantasai> jgilbert: maybe warn in UA<br> <fantasai> jgilbert: if called too often<br> <fantasai> jgilbert: but getDeviceClientRect() API alone ...<br> <fantasai> chrishtr: 2nd objection smfr raised<br> <fantasai> chrishtr: pixel-snapping requires more information than just layout in today's engines<br> <fantasai> chrishtr: in Chrome requires pre-paint step<br> <fantasai> chrishtr: in Safari requires paint<br> <fantasai> chrishtr: don't have solution to that problem<br> <fantasai> chrishtr: just note readback method for rAF<br> <fantasai> chrishtr: canvas.getThing<br> <fantasai> chrishtr: also has to run the same steps<br> <fantasai> Rossen_: but that's not blocking to accept the proposla<br> <fantasai> smfr: in some ways make sit worse<br> <fantasai> smfr: because 2 places we have to do this painting calculation<br> <fantasai> Rossen_: was asking if this second objection is blocking accepting the proposal<br> <fantasai> smfr: so to clarify the proposal is having API to return the box on canvas and also in ResizeObserver<br> <fantasai> smfr: I'm not a fan of doing partial paitn to get this info<br> <fantasai> smfr: I would expect for games , especially in full-screen, to position on ? boundaries<br> <fantasai> smfr: surprised if using fractional pixel positioning<br> <fantasai> jgilbert: for full-screen, unlikely, but for partial screen almost always get this<br> <fantasai> jgilbert: both on Windows and on Android, I believe, Windows will happily give you 1.6574 device pixel ratio<br> <fantasai> jgilbert: you just have to deal with it<br> <fantasai> jgilbert: you end up trying to reverse-engineer what pixel-snapping is to figure that out<br> <fantasai> jgilbert: pre-snap a rect to a non-integre CSS size , if that works out to integer pixels... then no artifacts? but it's a huge mess<br> <fantasai> smfr: other case that's confusing is on our iPhone's that have retina displays<br> <fantasai> smfr: already 2.7? scaling factors<br> <fantasai> smfr: so can cause hairlines to disappear aetc.<br> <fantasai> smfr: seems like also on windows, too<br> <fantasai> smfr: getting pixel perfection, seems like OS is doing scaling behind your back, how can you expect it to work?<br> <fantasai> jgilbert: out of the box cases where if you play around with virtual scaling<br> <fantasai> jgilbert: on a Mac and play with scaling on a retina screen<br> <fantasai> jgilbert: no way to get 1-1 device pixel<br> <fantasai> myles: even worse, the default ratio is not 1-1 or 2-1<br> <fantasai> jgilbert: it really depends on how the OS is doing this sort of scaling<br> <fantasai> jgilbert: I'll add that what you end up with, for instance in Mac, when you have this OS-level virtual resolution scaling<br> <fantasai> jgilbert: can't get one to one<br> <fantasai> jgilbert: if can't get 1-1 in application, can still get moire effects<br> <fantasai> jgilbert: can't entirely eliminate scaling artifacts, but can do better<br> <fantasai> jgilbert: than naively try to grid on the screen and hope it looks good<br> <fantasai> mattwoodrow: difference is on Windows the scaling isn't hidden<br> <fantasai> mattwoodrow: can attempt to match<br> <fantasai> jgilbert: windows 10 implements scaling that llows 1-1 rendering, not virtual scaling as default<br> <fantasai> jgilbert: Mac doesn't expose effective scaling, just says 2x all the time<br> <fantasai> jgilbert: Android says 3x all the time<br> <Rossen_> q?<br> <fantasai> ??: regarldess of what operating systems do, if application renders pixel -perfect<br> <fantasai> ??: Result will be better than if it wasn't<br> <fantasai> ??: I think we agree on that<br> <fantasai> myles: if goal is to get hairlines, even if you get a little closer to hairline, can still disappear<br> <fantasai> ??: Display scaling might give you smoother color if checkerboard is pixel-perfect before the scaling<br> <fantasai> ??: and if you have checkerboard before scaling, then less smooth design<br> <fantasai> s/??/mstage/<br> <jgilbert> s/mstage/mstange/<br> <fantasai> mstange: still discussing value of getting an accurate box? what's status?<br> <fantasai> jgilbert: if we decide that we don't want to give ppl this box, then ?<br> <fantasai> 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?<br> <fantasai> mstange: what we would need to do in Firefox to get this result<br> <fantasai> mstange: Firefox takes into account the full zoom, and takes into account CSS Transforms<br> <fantasai> mstange: space in which we snap is established by the closest non-animated transform or the root<br> <fantasai> mstange: we only know this info during painting<br> <fantasai> mstange: so would need to run more steps before giving info<br> <fantasai> smfr: this device border box would not be affected by transforms<br> <fantasai> smfr: so would have to do *special* calculation<br> <fantasai> jgilbert: 3D transforms no idea what to fee dback<br> <fantasai> jgilbert: pixel-snapped bounding box?<br> <fantasai> atotic: if you're doing transforms won't be pixel-perfect anyway, so don't worry about it<br> <fantasai> atotic: your'e also talking about implementation that you need to get this nformation during pre-painting<br> <fantasai> atotic: remember you had this information ??<br> <fantasai> atotic: Might be ok to deliver incorrect information and not have to paint<br> <fantasai> myles: there's a chance of you never get correct info<br> <mstange> s/closest non-animated transform/closest animated ancestor transform/<br> <fantasai> atotic: I think you want, once things have settled down want accurate box size<br> <fantasai> atotic: if animating, don't care so much<br> <fantasai> jgilbert: deliver informmation lately<br> <fantasai> jgilbert: would be nice if we could try so that you could do 1-1 perfect every time within certain set of constraints<br> <fantasai> jgilbert: be nice if we didn't immediately settle on a 1 frame late policy<br> <fantasai> jgilbert: matching what native APIs are able to do<br> <fantasai> jgilbert: don't want to suffer if dont' have to suffer on native<br> <fantasai> 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<br> <fantasai> myles: similarly, worried that we'd have to reverse-engineer chrome's pixel-snapping strategy<br> <fantasai> jgilbert: shouldn't have to do more normalziation than you do today, I think<br> <fantasai> jgilbert: if trying to use this to get anti-moire, in order to do this today have to ??<br> <fantasai> smfr: one frame late version also problem of which rectangle to trust<br> <fantasai> chrishtr: not late if layout occured<br> <fantasai> chrishtr: only late if you have a threaded animation<br> <fantasai> smfr: thought it would be late because we woudl collect info at paint time<br> <fantasai> chrishtr: I don't think we shoudl do that, disagree with atotic<br> <fantasai> chrishtr: think we can do it therefore we should<br> <fantasai> chrishtr: in cases where layout has occured<br> <fantasai> chrishtr: agree with point about threaded animations and not syncing with JS thread<br> <fantasai> smfr: want to tie together two of previous points, first that if we implement this paint day device pxel border box, will be more expensive for us<br> <fantasai> smfr: secondly because of physical mismatch, wouldn't have some user benefit<br> <fantasai> smfr: display is scaling anyway<br> <fantasai> smfr: can we get examples?<br> <fantasai> smfr: want to try on Apple devices, see what would happen if looks right<br> <fantasai> atotic: moire patter<br> <fantasai> atotic: if you're moving canvas around the screen, the moire is animated. looks really bad<br> <fantasai> smfr: please give us some tests<br> <fantasai> chrishtr: I think time is up?<br> <fantasai> chrishtr: propose to add the feature?<br> <fantasai> Rossen_: does the group feel there's enough merit to add this?<br> <fantasai> Rossen_: would be adding both APIs<br> <fantasai> Rossen_: is there any objection?<br> <fantasai> smfr: I dont' think we can accept new API without evidence that it's so much better that it's worth the extra cost<br> <fantasai> fremy: you can agree with the API and just return some approximate result if you feel it's good enough<br> <fantasai> myles: your'e saying implement the API without implementing teh API<br> <fantasai> fremy: might not be useful on your device<br> <fantasai> fremy: but might be useful on Android<br> <fantasai> fremy: so just return the result<br> <fantasai> AmeliaBR: Not having an API is better than having API with bad results<br> <fantasai> AmeliaBR: if a particular browser has particular concerns about implementing the particular API<br> <jgilbert> 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<br> <jgilbert> ... I still need to size my box either way<br> <jgilbert> ... if my choice is I can get teh actual device pixel size from Chrome, but calcaulate it myself from widht/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<br> <jgilbert> ... then I only need to write one code flow<br> <fantasai> AmeliaBR: might make sense, but have existing cases where you can't trust the API<br> <fantasai> florian: In general I agree with your statement, this doesn't seem to be such a case<br> <fantasai> Rossen_: I woudld like to end this topic<br> <fantasai> Rossen_: going to call for objections to adding the API, if we have objections we'll deal with them and have additional conversatiosn with the TAG and whatnot<br> <fantasai> Rossen_: any objections to having these APIs?<br> <fantasai> smfr: Can we wait until we ahve the examples?<br> <fantasai> astearns: I might object because seems like we need more data<br> <fantasai> astearns: so I will object on Safari's behalf<br> <fantasai> Rossen_: so back to you to get test cases, we'll discuss again on telecon<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-532066457 using your GitHub account
Received on Tuesday, 17 September 2019 05:36:06 UTC