- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Mar 2023 17:02:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Define behaviour when capturing image for a large element.`, and agreed to the following: * `RESOLVED: user agent can limit rasterization for performance limitations, but must size the element as if it was fully rasterized` * `RESOLVED: rasterization must cover at least the visible area of the viewport` <details><summary>The full IRC log of that discussion</summary> <emeyer> JakeA: When we capture the content of an old view, we don’t know how it might be animated yet<br> <emeyer> …Part of the element might be out of view, and could come in view as part of the transition<br> <emeyer> …Some elements are very large and we can’t feasibly capture all of it<br> <emeyer> …Image transitioning the body element<br> <emeyer> …Proposal is, we’ll base the dimensions of the transition group on the element, but say that browsers don’t have to capture every pixel, while suggesting they capture beyond the viewport<br> <emeyer> …If possible/performant to do so<br> <emeyer> …Are we okay to handwave like that, so we let UAs act as they see best?<br> <TabAtkins> q+<br> <emeyer> …Further, what should the natural width and height of the in- and out-states be when a browser chooses not to capture every pixels?<br> <emeyer> …Also, should those things be script-visible?<br> <khush> q+<br> <emeyer> TabAtkins: I think we should require at least the visible area and some amount outside is good, maybe with a minimum explicit margin like 50% beyond<br> <Rossen_> ack TabAtkins<br> <emeyer> …We should expose the size of the thing being captured<br> <emeyer> fantasai: +1 to Tab, plus the size should be the size it actually is, even if there isn’t painting inside the entire range<br> <flackr> +1<br> <emeyer> …We should require or very strongly recommend capturing beyond the viewport as well<br> <Rossen_> ack fantasai<br> <emeyer> JakeA: So if there’s a case with many elements layered on top of each other, they’re all in the viewport; if device can’t handle all that, should we just skip the transition?<br> <emeyer> …I think that’s a good general case, that if a UA doesn’t feel it can handle a given transition, it should skip the transition<br> <fantasai> s/as well/as well, probably +1 viewport in each direction as the minimum range to capture/<br> <emeyer> khush: +1 to fantasai, which is kind of what I was implementing anyway, so I’m okay with the spec recommending taking the root as a barometer for how much to expand beyond the visible viewport<br> <emeyer> …The spec says the natural size of the image is equal to what you capture and everything around it is transparent<br> <emeyer> …object view box exposes how much the UA decided to paint<br> <chrishtr> q+<br> <emeyer> fantasai: I don’t think you should use object view box to set this, even if you use the same computation internally<br> <emeyer> khush: So the computed value is meant to be ink-overflow-rectangle<br> <Rossen_> ack khush<br> <emeyer> chrishtr: We would just not raster things we can’t put into memory, so developers can’t observe anything about this behavior<br> <emeyer> fantasai: Exactly<br> <flackr> +1<br> <vmpstr> q?<br> <emeyer> JakeA: We can say the exposed value doesn’t say anything about optimizations<br> <emeyer> vmpstr: I think the object view box is the problem, because we need to make it the same as ink overflow, but if that’s infinite\<br> <emeyer> flackr: It’s the same as if you hadn’t rendered everything<br> <emeyer> khush: In the spec it says to paint everything in the ink overflow rectangle<br> <emeyer> …We pretend an image is the size of the ink overflow rect<br> <emeyer> chrishtr: A dev wouldn’t know whether we painted the whole thing or not, only the user can tell<br> <khush> q+<br> <Rossen_> ack khush<br> <emeyer> khush: Base case where the UA can raster the whole thing, and element has drop shadow, so ink overflow is bigger than object box<br> <chrishtr> q+<br> <emeyer> …UA should compute a view box it applies to the element such that when you render this, the boxes should coincide at the same origin<br> <emeyer> …If the UA hasn’t painted the whole thing, and the dev msses with the object view box, the effect is the same as if the whole thing was painted<br> <emeyer> …My question is, to implement this, can we not let devs change object view box?<br> <emeyer> …When they read it, we can give the the value the spec wants; also the device specs wouldn’t be exposed?<br> <flackr> q+<br> <emeyer> fantasai: What is the ink overflow rectangle of something that has a box shadow?<br> <emeyer> chrishtr: There’s spec language about this<br> <emeyer> fantasai: Do we want to expose this?<br> <flackr> q-<br> <emeyer> khush: You could call getcomputedstyle and don’t see anything, which would make implementation easier<br> <emeyer> fantasai: That seems better, and if the dev wants to manipulate they don’t have to know about the internals<br> <emeyer> chrishtr: We could take this and whether we should add a new !important to a new rule<br> <emeyer> fantasai: I think we agree the rasterization is not exposed to devs but the returned values are spec-consistent<br> <Rossen_> ack chrishtr<br> <fantasai> proposal: UA can limit rasterization for perf limitations, but must size the element as if it was fully rasterized<br> <emeyer> chrishtr: Agreed<br> <emeyer> JakeA: I think we generally agreed the spec should suggest an overflow amount, was it one viewport in each direction?<br> <fantasai> proposal: rasterization should cover at least the visible area of the viewport + one viewport in each direction<br> <emeyer> JakeA: Also in out-of-memory cases the transition is skipped<br> <fantasai> proposal: if the UA cannot performantly perform the view transition (for any reason) it must skip the transition<br> <emeyer> TabAtkins: We don’t usually specify memory problem recovery because it can show up whenever<br> <emeyer> fantasai: I think we have three proposed resolutions<br> <emeyer> …One (see above)<br> <TabAtkins> Exception is if OOM actually causes a security issue. In all other cases OOM behavior is explicitly undefined.<br> <emeyer> …Two look one viewport in each direction for overflow handling<br> <emeyer> …Three is the error fallback is to skip the transition<br> <khush> q+<br> <emeyer> …And that you never do half a transition, you either do all or none<br> <emeyer> khush: One viewport in each direction should be a recommendation rather than a requirement<br> <emeyer> …Only requirement is that what’s visible must be captured<br> <fantasai> proposal: UA can limit rasterization for perf limitations, but must size the element as if it was fully rasterized<br> <fantasai> proposal: if the UA cannot performantly perform the view transition (for any reason) it must skip the transition<br> <fantasai> proposal: rasterization should cover at least the visible area of the viewport + one viewport in each direction<br> <emeyer> RESOLVED: user agent can limit rasterization for performance limitations, but must size the element as if it was fully rasterized<br> <JakeA> proposal: Must: rasterization should cover at least the visible area of the viewport Should: + one viewport in each direction<br> <JakeA> proposal: Must: rasterization should cover at least the visible area of the viewport<br> <flackr> must + should = ?<br> <JakeA> proposal: Must: rasterization covers at least the visible area of the viewport<br> <emeyer> RESOLVED: rasterization must cover at least the visible area of the viewport<br> <emeyer> JakeA: We need to consider the directions and how much overflow SHOULD be captured async<br> <flackr> q+<br> <Rossen_> ack khush<br> <bkardell_> I think no<br> <emeyer> flackr: Skipping the transition is dev-visible so we’re exposing device capabilities<br> <emeyer> fantasai: You can limit rasterization but if you’re getting to the point you can’t even transition what’s on-screen, you should skip the whole thing<br> <bkardell_> q+<br> <Rossen_> ack bkardell_<br> <emeyer> flackr: We could not paint the transition but still run it so the dev knows it happened<br> <emeyer> bkardell_: You’re saying skipping the transition is dev-visible but is it? Because a device can just not support that or animations can be turned off with prefers-reduced-motion<br> <emeyer> Jake:We’ve decided those can be exposed, but giving away GPU memory is a fingerprint<br> <emeyer> bkardell_: I see<br> <emeyer> khush: Is it safer to say that this should silently fail by not painting things?<br> <emeyer> …We can already hit this with filters and blurs and such and that’s silent in Chrome<br> <emeyer> JakeA: I think we have to go back and come up with a plan here<br> <emeyer> Rossen: So we’ll have to postpone this resolution<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8561#issuecomment-1470414852 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 March 2023 17:02:22 UTC