- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Feb 2019 18:13:41 +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> <gregwhitworth> Topic: ResizeObserver device-pixel-border-box<br> <gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3554<br> <gregwhitworth> atotic: I've been working on the spec<br> <gregwhitworth> atotic: the graphics team came to me - the problem they have is a way to determine the device pixel size of canvas<br> <gregwhitworth> atotic: why do they need to do this - the reason why they need to do this - is there is no way to do this<br> <gregwhitworth> atotic: the way the devs do hidpi in canvas it has CSS Pixels and what they do is they create the bitmap size they create the canvas in physical pixels it gets shrunk to CSS pixels so they can draw really fine hairlines<br> <gregwhitworth> atotic: device pixels are never rounded - there is no doubles or floating point, etc<br> <gregwhitworth> atotic: how we do this is by pixel snapping, there is no way for webdevs to determine this<br> <gregwhitworth> atotic: pixel snapping depends on not only pixels but also position<br> <gregwhitworth> atotic: I asked to add it to canvas, and they said sure but they also need to be notified when its resize<br> <gregwhitworth> atotic: currently the proposal will be that you will get device pixel inline and border size if its a canvas<br> <gregwhitworth> fantasai: are you proposing to add it somewhere else<br> <gregwhitworth> atotic: no<br> <gregwhitworth> fantasai: so the only way to get this is to add the resizeObserver<br> <gregwhitworth> atotic: yes<br> <gregwhitworth> dholbert: does devicePixelRatio?<br> <gregwhitworth> atotic: they get a bad pattern from hacking this because it can't do pixel snapping correctly<br> <gregwhitworth> dbaron: under what conditions does Chrome change the device pixel backing size when it's repositioned?<br> <gregwhitworth> dbaron: atotic is saying that, if you make a subpixel change in the top coordinate of a canvas, if it's 100.25 px tall<br> <gregwhitworth> dbaron: and it's top is positioned at a pixel aligned position it would round to 100, if it's further down it will be 101<br> <gregwhitworth> dbaron: do you actually change the backing store<br> <gregwhitworth> dbaron: the number of image pixels in the canvas<br> <gregwhitworth> dbaron: I guess thats the height and width<br> <gregwhitworth> dbaron: they want to change those the attrs based on the device pixel sizes<br> <gregwhitworth> atotic: the developer determines the size of the backing store, what Chrome does it will copy that bitmap to the CSS size of the canvas, if the ratio is a nice even number then we don't get moar patterns - if we don't<br> <bkardell_> how is that different from a url background image?<br> <gregwhitworth> atotic: there is a CSS size which can be fractional - but there is also the real bitmap to paint the canvas and that bitmap is in physical pixels<br> <bkardell_> " if the ratio is a nice even number then we don't get moar patterns - if we don't"<br> <bkardell_> that bit<br> <TabAtkins> s/moar/moire/g<br> <gregwhitworth> dbaron: bkardell_ is asking why don't you get moire pattern in background images<br> <gregwhitworth> atotic: it will scale, but background image is fundamentally different<br> <bkardell_> I can unmute and talk, I just dont want to interupt and don't knwo if this is enough to warrant a q<br> <gregwhitworth> atotic: we probably do get them but you usually aren't doing hidpi background image or you can't tell<br> <gregwhitworth> atotic: where they primarily have this issue is in the 3d context and they'll have patterns that look different<br> <AmeliaBR> q+<br> <gregwhitworth> bkardell_: the act of painting a thing on a canvas - the bitmap comes from an image and we rescale the image - it shoudln't matter who creates this image?<br> <gregwhitworth> atotic: you will see artifacts - but they'll create 3 different images<br> <dbaron> So I understand the use case -- but I'm a little suspicious of making it <canvas>-only, though.<br> <gregwhitworth> iank_: within painting, we know where the pixel snapping is so we can account for it<br> <gregwhitworth> atotic: also we're talking about every frame in video games, it happens a lot more<br> <gregwhitworth> dbaron: I understand the usecase I just don't know if I like that it's canvas only<br> <florian> q+<br> <gregwhitworth> atotic: I agree, but there is a performance penalty to calculate them and most people don't care about this except in a canvas context<br> <dbaron> I'd have expected it to be implemented a different way, but okay...<br> <gregwhitworth> atotic: if we find that it's useful in other areas it's easy to extend it<br> <gregwhitworth> AmeliaBR: if this is a canvas thing - why are we doing this here. Especially since this is a really hacky way to do it<br> <gregwhitworth> atotic: from what I understand from the history, there was a hidpi way in which to do this but the other standard didn't go anywhere<br> <gregwhitworth> hober: we also saw that people still create the larger one<br> <gregwhitworth> atotic: I agree RO is an odd place but the dimensions change if you move around you still need to be notified<br> <gregwhitworth> liam: checking the device pixel size, it seems easy to check every frame<br> <AmeliaBR> ack me<br> <gregwhitworth> liam: why would you not check it?<br> <gregwhitworth> atotic: if you're a game developer maybe<br> <heycam> q+<br> <gregwhitworth> frremy: If you want to draw a perfect line in your table you'll need to resnap it<br> <gregwhitworth> atotic: exactly, you need it or you add it to both specs<br> <heycam> ack florian<br> <emilio> q+<br> <gregwhitworth> florian: another thing - here we know what CSS & device pixel things and very easy to get confused<br> <gregwhitworth> florian: I don't know exactly what we want to add so let's not add it to too many places because it will get misused<br> <emilio> ack heycam<br> <gregwhitworth> atotic: it would only happen on canvas - you would see inlineDevicePixel and blockDevicePixel<br> <Rossen> gregwhitworth, recaps the resolution from yesterday<br> <gregwhitworth> heycam: before you were seeing a perf penalty - why not add a new box watching keyword?<br> <gregwhitworth> heycam: you can still have the device pixel border box of another element<br> <gregwhitworth> florian: but that was my point - if you make it broadly available they'll abuse it<br> <gregwhitworth> florian: they'll think they want device pixels but they'll probably be incorrect<br> <bkardell_> q+<br> <gregwhitworth> liam: to be clear, the only usecase this solves compared to RO plus having a method on canvas<br> <bkardell_> q-<br> <florian> q-<br> <dholbert> q+<br> <gregwhitworth> liam: this canvas snapping happens during painting or layout? If it happens at painting you wouldn't want to wait for painting to be done<br> <emilio> s/liam/emilio<br> <gregwhitworth> smfr: the only way to really know this you is to do it at painting you have to take transforms into account<br> <gregwhitworth> Rossen: if you have a scale it's broken<br> <florian> ScribeScribe: Florian<br> <gregwhitworth> gregwhitworth: I'm against adding this based on what smfr and liam said<br> <gregwhitworth> atotic: it will be blurry anyways so it doesn't matter<br> <emilio> s/liam/emilio again :D<br> <florian> gregwhitworth: in your use case, you may be right, but if we add this, there may be people who want to use it in the more general case that includes tranforms<br> <florian> gregwhitworth: so taking all web devs into account, this looks like a partial solution, not good enough<br> <gregwhitworth> iank_: I'll need to ask Chris, but we may compute the transforms<br> <gregwhitworth> atotic: resizeObserver doesn't watch transforms<br> <gregwhitworth> smfr: then this is the wrong API to bolt this onto<br> <gregwhitworth> atotic: ok, the hidpi with an ancestor that has a transform or something<br> <gregwhitworth> atotic: that should still work because it will then get transformed<br> <gregwhitworth> florian: then it's broken because the second you scale it's broken<br> <gregwhitworth> florian: people will assume they can and it will fail<br> <gregwhitworth> atotic: I thought one of the issues on the webplatform you don't want to expose zoom because it will break<br> <gregwhitworth> heycam: this is different<br> <heycam> s/this/pinch zooming and transforms on ancestors/<br> <gregwhitworth> atotic: we were talking about the pinch zoom of the page and they would end up with arbitrarily long page<br> <gregwhitworth> florian: pinch zoom, leaving it out - but transform?<br> <gregwhitworth> atotic: if we were going to do transforms, there will be a subset of these that should work<br> <gregwhitworth> atotic: we want this to be a size API not a quad API<br> <florian> gregwhitworth: I feel this is a chrome only perspective, safari and Firefox don't seem up to it. Should we go back to the github issue?<br> <gregwhitworth> atotic: RO itself does not work with transforms<br> <gregwhitworth> fremy: If you're going to draw a canvas you're not trying to do a transform on top of that<br> <gregwhitworth> fremy: transform is for animations<br> <gregwhitworth> fremy: why would you intend to do this if you're focused on pixel perfect drawing<br> <gregwhitworth> liam: I agree it doesn't make sense, it does make sense to center a canvas<br> <gregwhitworth> florian: offset path will also impact this as it can change the position<br> <gregwhitworth> atotic: we're going to notify you when the border box changes<br> <gregwhitworth> atotic: there's nothing that says we're not going to change on the transforms<br> <gregwhitworth> dholbert: how integral is the movement of the subpixel<br> <gregwhitworth> atotic: when you're moving it's blurry anyways, it's a video game<br> <gregwhitworth> dholbert: I'm feeling like a static API is more desirable than an RO API<br> <bkardell_> it is possible to make a subclass phase 2 of this that was specifically for observing that?<br> <bkardell_> .. or something<br> <gregwhitworth> dholbert: the canvas API makes sense to have this<br> <gregwhitworth> atotic: but people want to get an observation<br> <fremy> q+<br> <emilio> ack emilio<br> <dholbert> q-<br> <gregwhitworth> AmeliaBR: is it reasonable to trigger RO on something may have changed even if the sizes haven't changed - they then can do a canvas pixel<br> <gregwhitworth> atotic: I thought of that - but you end up getting a bunch of ROs without knowing why<br> <gregwhitworth> AmeliaBR: we have a way of adding device-pixel-border-box back?<br> <gregwhitworth> atotic: where most observers they look at the border box or content box, what is this box and creates a larger turbelance<br> <gregwhitworth> AmeliaBR: maybe I don't care about those and you're adding a perf hit<br> <gregwhitworth> heycam: you can rename the type of the box, canvas-bitmap-box if you're worried about<br> <gregwhitworth> atotic: it kind of locks us into watching the canvas only<br> <gregwhitworth> fantasai: I think agree with atotic named canvas - so we shouldn't lock that down<br> <fantasai> s/named/about not naming specific to/<br> <gregwhitworth> smfr: we simply snap device scale factor - if you're inside the scale transform we don't snap all the time, so we do need to go outside of layout a bit.<br> <fantasai> fantasai^: because there might be other elements in the future where we want to use it, and we should be able to just re-use the same thing for those cases<br> <gregwhitworth> atotic: it has a perf hit<br> <gregwhitworth> smfr: if you drag to another screen would it fire<br> <gregwhitworth> atotic: yes<br> <gregwhitworth> smfr: it's not real device pixels, because your not taking transforms into account<br> <gregwhitworth> chrishtr: its the dims of the texture of the backing store<br> <gregwhitworth> smfr: what you just said is very impl specific<br> <gregwhitworth> chrishtr: it's the CSS pixel size snapped and multiplied by the devicePixelRatio without taking into account transforms<br> <gregwhitworth> chrishtr: it has to take into account zoom<br> <gregwhitworth> smfr: ours doesn't<br> <gregwhitworth> chrishtr: the spec says to<br> <gregwhitworth> dholbert: doesn't it fire after layout?<br> <gregwhitworth> atotic: yes<br> <gregwhitworth> dholbert: so after layout<br> <gregwhitworth> dholbert: it would need to be extended to take into account after the fact<br> <gregwhitworth> liam: I don't think this a great fit<br> <gregwhitworth> iank_: it's where all other resizes are triggered, it's actually bad to try to keep it in sync with RO<br> <myles__> q+<br> <dbaron> So about 20 minutes ago there was a suggestion to take this back to the github issue... is there something we're actually going to resolve on here?<br> <gregwhitworth> fantasai: one thing to note if we have a RO if your 100 CSS pixels and I move it to the hidpi screen it's still 100 CSS pixels. And it's a canvas specific issue<br> <gregwhitworth> fantasai: it would be nice to not get the extra events unless I actually care about the device pixel border box<br> <gregwhitworth> atotic: yes<br> <gregwhitworth> fantasai: I think it should be the content box since that's what you're painting into<br> <dbaron> atotic: you could register to observer device-pixel-content-box<br> <gregwhitworth> atotic: that was my original proposal<br> <chrishtr> q+<br> <xfq> ack my<br> <gregwhitworth> myles__: so in conjuction with what fantasai was saying then you need to know the pos and size.<br> <gregwhitworth> fantasai: no only if those pixels change<br> <florian> gregwhitworth: that's already in the algo<br> <gregwhitworth> fantasai: you can resize in result of pos, but it may not<br> <Rossen> ack fremy<br> <gregwhitworth> fremy: I think it's going to be tricky in a sense, for the usecase your using - have you considered the paint() API?<br> <dbaron> (sounds like people were leaning towards registering for a separate box name rather than giving these notifications magically in some case)<br> <gregwhitworth> iank_: we don't have webgl and a bunch of other APIs<br> <gregwhitworth> fremy: oh ok<br> <fantasai> Proposal: Register for changes to devicePixelContentBox, get back sizes in device pixels, throws an error if registered on anything other than a canvas element, fires whenever device pixel size changes whether due to change in screen resolution, element position, or element resizing. Does not fire if device pixel size does not change.<br> <smfr> q+<br> <dbaron> still doesn't deal with the issues about rectilinear transforms, offset-path, etc.<br> <Rossen> ack chrishtr<br> <gregwhitworth> chrishtr: I just wanted to follow up on explicitly defining the API, in the CSS paint worklet callback you can see the device pixel backing size. It helps devs to dinstinguish between the two and can discover it. I think it would be useful to distinguish<br> <gregwhitworth> atotic: I think we have agreement to watch a seperate box?<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <gregwhitworth> smfr: I just want to say that I don't think canvas is the only one, I think other situations may care about the same thing<br> <gregwhitworth> smfr: I think people will want it in other ways<br> <astearns> ack smfr<br> <smfr> s/in other ways/on other elements/<br> <gregwhitworth> smfr: I was proposing this is the snapped content box multiplied by device pixel ratio<br> <gregwhitworth> dbaron: but you all agree to ignore transforms?<br> <gregwhitworth> chrishtr: because it should be a paint based situation for perf<br> <gregwhitworth> dbaron: I don't think that's actually true<br> <gregwhitworth> chrishtr: unless overflow it's almost post paint<br> <gregwhitworth> krit: even SVG?<br> <AmeliaBR> I like the connection with Paint API. Even comes with a nice name, "paint size": https://drafts.css-houdini.org/css-paint-api/#paintsize<br> <gregwhitworth> Rossen: my proposed closing of the issue - let's bring the proposal back to github and then bring it back and we can resolve then<br> <gregwhitworth> atotic: thank you<br> <TabAtkins> Ooh, "paint size" sounds good.<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-467550497 using your GitHub account
Received on Tuesday, 26 February 2019 18:13:43 UTC