Thanks for working on this! It may be interesting to think through if/how this interacts with other prioritization work (on the network or on the script scheduling side). Adding Pat and Scott for visibility.
On Tuesday, September 21, 2021 at 10:08:03 PM UTC+2 Vladimir Levin wrote: > Contact emails > > > *[email protected]*Explainer > > > *https://github.com/WICG/display-locking/blob/main/explainers/update-rendering.md > > <https://github.com/WICG/display-locking/blob/main/explainers/update-rendering.md>* > Summary > > > > > *The web includes a number of features and heuristics (such as > content-visibility, containment and others) that allow the User Agent to > skip rendering work for elements and contents of elements that are not > visible to the user. This is done with the intent to allow other content, > animations and interactions to remain smooth and get as much CPU time as > possible. However, there are situations where this neglects the site intent > of showing currently skipped content shortly. In other words, if the > website intends to show an element whose contents are currently skipped, > then skipping work may cause jank when the contents are ultimately > presented.The renderpriority attribute is an HTML attribute that informs > the User Agent to keep the element's rendering state updated with a > specified priority.*Blink component > > > *Blink>Paint > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPaint>*TAG > > review > > > *https://github.com/w3ctag/design-reviews/issues/676 > <https://github.com/w3ctag/design-reviews/issues/676>*TAG review status > > > *Pending*Risks > > > *This is a new performance feature that allows the User Agent to break up > the rendering work over several frames. It has minimal risk. We need to > ensure that we consider timing > <https://github.com/WICG/display-locking/issues/208> as a potential attack, > but I think that can be mitigated.*Interoperability and Compatibility > > > > > > > *Since this is a new feature that does not affect anything other than the > timing of the rendering work, there is no risk to interoperability and > compatibility: User Agents that don't support the feature would essentially > treat the rendering work as synchronous when it is presented. This is no > different from what happens today. User Agents that do support the feature > would be able to make iterative progress on the rendering work, thus having > a shorter delay when the content is ultimately presented.Gecko: No > signalWebKit: No signalWeb developers: Positive (partner feedback in email > -- I'll work on getting public signals)*Debuggability > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > > *No. I will add tests, although being a performance primitive this may be > difficult to test.*Requires code in //chrome? > > > *False*Tracking bug > > > *https://bugs.chromium.org/p/chromium/issues/detail?id=1251363 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1251363>*Estimated > milestones > > > > *No milestones specified*Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5764311403200512 > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/11b05dd3-e9be-46ee-b246-44b857592617n%40chromium.org.
