- From: Stephen McGruer via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 19:42:50 +0000
- To: public-css-archive@w3.org
To add some background to this issue; kevers@ is currently looking at our (Chrome's) cubic bezier implementation, in particular why we fail the WPT tests such as https://wpt.fyi/results/css/css-easing (and some of the related CSS and web animation tests). As is common, it is a question of performance vs accuracy; [Chrome's implementation](https://cs.chromium.org/chromium/src/ui/gfx/geometry/cubic_bezier.cc?l=139&rcl=def2963f36b722a0c03e6bafdfaa4062b7ec4d16) first tries 8 iterations of Newton's approximation, then if that fails to find an answer with an acceptably small error rate it falls back to doing a bisection until again we have a sufficiently small error (or until we fail). We also use quite a coarse error epsilon, again for performance. This is different from the bar used in the tests, which IIRC what kevers@ told me is 30 rounds of the bisection method. kevers@ is investigating the performance impact of improving our accuracy here, but we noticed that there is no comment on or allusion to acceptable error in the spec. The WPT tests often use answer +- 0.01, but it is unclear how or why this was chosen. I believe it would help interop if we could agree on a reasonable way to define the expected accuracy, or otherwise at least spec (perhaps via a non-normative notice) that results may change slightly between web agents due to performance considerations when modelling bezier curves. -- GitHub Notification of comment by stephenmcgruer Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4014#issuecomment-499639317 using your GitHub account
Received on Thursday, 6 June 2019 19:42:52 UTC