W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

Re: [csswg-drafts] [css-transforms] Provide a way to specify rastered content scale for transformed content (#236)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 30 Oct 2019 17:05:02 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-548011810-1572455100-sysbot+gh@w3.org>
The CSS Working Group just discussed `Provide a way to specify rastered content scale for transformed content`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Provide a way to specify rastered content scale for transformed content<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/236<br>
&lt;dael> smfr: Browser have traditionally rasterized elements to gpu texts when authors apply something like 3d transforms.<br>
&lt;dael> smfr: Various attempts by impl to choose a good scale. User says scale-3d 2,2,1 At least in WK we don't re-rasterize so it becomes pixelated. Re-raster is hard because if content is dynamic what scale? Right thing is let the author decide since they're only one that really knows what's going to happen?<br>
&lt;dael> smfr: This issue proposes a new property to let authors spec rasterization scale. Reasonable. UA should be able to decide not to use that scale for reasons like memory<br>
&lt;TabAtkins> chrishtr: I'm not sure what the right API shape should b eand how we should describe it<br>
&lt;TabAtkins> smfr: I assume it would be `scale-suggestion: 2` or something<br>
&lt;TabAtkins> (i made up the property name)<br>
&lt;TabAtkins> AmeliaBR: I assumed `max-expected-scale`<br>
&lt;TabAtkins> AmeliaBR: Transforms are cumulative tho; needs some detail about how much accumulation is expected.<br>
&lt;TabAtkins> dbaron: Gecko at some point in the past tried to do smarter things, and we did occasionally hit things where devs had an expectation of the simpler WebKit behavior.<br>
&lt;TabAtkins> dbaron: One example was a very quick zoom-in animation; it loads by starting big and quickly shrinking to the correct size.<br>
&lt;TabAtkins> dbaron: We had a bug where we were rasterizing with too much memory in that situation. This animation was on the firefox home screen so it was detected.<br>
&lt;TabAtkins> dbaron: So we did see some cases where authors didn't want the logical rasterize to be at the highest density point, because it was zoomed thru quickly enough to not matter.<br>
&lt;TabAtkins> chrishtr: I wonder if it would work to have someting that declares it will animate, with the curve or the balance.<br>
&lt;TabAtkins> AmeliaBR: Maybe add more info to will-change<br>
&lt;TabAtkins> AmeliaBR: will-change:transform isn't a lot of help; different optimization for transform vs scaling<br>
&lt;TabAtkins> dbaron: I think will-animate isn't necessarily enough. Some animations are slow and you want detail; others are fast and you don't.<br>
&lt;TabAtkins> Rossen_: So we're over time. Take this back to the issue.<br>
&lt;Rossen_> trackbot, end meeting<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/236#issuecomment-548011810 using your GitHub account
Received on Wednesday, 30 October 2019 17:05:04 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:55 UTC