|
|
| Composite background-color animation |
| xidachen@ has been working on this feature aiming to relaunch the finch experiment. There are a few problems fixed during this sprint. |
| |
| The first one is decouple paint and compositing, which is shown in the above diagram. Before, we call “CheckCanStartAnimationOnCompositor” during the paint stage to determine whether the element should be painted off the main thread or not. Then at the compositing stage, we call the function again to determine whether or not the animation can run on the compositor thread. This causes problems because the property tree node can change during the paint and compositing. The problem is now fixed in this CL, by not calling the above function during the paint stage, which requires us to implement a paint worklet code path to paint the element off the main thread. |
| |
| The second problem is missing repaint in a few cases, which is tracked in this bug. During this sprint we have fixed most of them. |
<td><td>The first case is missing repaint when the background is transparent
during the animation. It is fixed in this <a
href="https://chromium-review.googlesource.com/c/chromium/src/+/2739318">CL</a>.
The animated gif on the left shows a background-color animation runs
correctly with the first frame being transparent.</td></td>
<td><td>The second case is background-color animation on table row or table
col, whose background is painted into its table cell. In this case, we let
the animation fall back to the main thread. This is fixed by this <a
href="https://chromium-review.googlesource.com/c/chromium/src/+/2774182">CL</a>.</td></td>
<td><td>The third case is background-color animation on the body animation,
while the view is responsible to paint its background. It is fixed by this
<a
href="https://chromium-review.googlesource.com/c/chromium/src/+/2779551">CL</a>,
which lets the animation run on the main thread.</td></td>
| Experimental: native paint worklet |
| |
| Our team is partnering with the skia team, to develop a variant of CSS paint worklet (a native paint worklet), to paint the background faster using native code. |
| The picture on the left shows example usage (full JSBin example). In the example, we don’t need to use the traditional CSS paint APIs such as “addModule” or “registerPaint”. Rather we use the “skottie” as the name to identify that this is native paint worklet. |
| The change is in a work-in-progress CL, currently the animation is running on the main thread, we need some more work to move it off the main thread. |
| Declarative show-hide explainer |
| |
| flackr@ published an explainer for the plethora of options to implement tabs. |
| It has received early feedback from Brian Kardell regarding additional constraints and other options. |
|
| |
|
| Chapter II: Testing |
| liviutinta@ fixed flaky test pointer_event_pointercapture_in_frame in this CL. Specifically, the issues found are: |
<td><td>Successive test_driver.Actions().pointerMove might lead to coalesced
pointermove events.</td></td>
<td><td>test_driver.Actions().send() is asynchronous, the test assumed that
it was synchronous.</td></td>
<td><td>Differences between the test_driver.Actions() event streams between
Windows/Linux.</td></td>
<td><td>Order of pointerup/lostpointercapture when pointer travels across
frames not well defined. Opened <a
href="https://github.com/w3c/pointerevents/issues/355">PEWG</a> issue. This
still leads to rare flaky runs.</td></td>
|
| |
|
| Chapter III: Stability fixes |
|
| |
|
| CHECK failure during cc animation timing calculation |
| |
| kevers@ worked on the problem where cc does timing calculations a bit differently from WAAPI with respect to animations. The problem is shown in the above code snippets. We verified the timing conversion as part of the check for eligibility to run on the compositor, but we didn’t consider time_offset when making the determination. The solution is to include time_offset in the calculation. |
| Crash GestureNavSimple::OnOverscrollModeChange |
| |
| flackr@ fixed a crash that is due to object lifetime issue. The problem is that an unowned pointer was given to the RenderWidgetHostViewAura’s OverscrollController delegate, when the view did not guarantee that the delegate stayed alive. In some cases the web contents (and delegate) could be destroyed before the view resulting in using the deleted delegate. |
|
|
| Browser-verified user activation shows misleading data! |
| mustaq@ worked on the finch experiment on browser-verified user activation. Currently the finch data suggests verification failure rate is about 0.7%. |
<td><td>Similar failures even in the Control groups where the feature is
disabled.</td></td>
<td><td>The Control group is consistently better/worse than the Enabled
groups.</td></td>
<td><td>This is the <a
href="https://docs.google.com/document/d/1_4Tg9Bt1OXO6mjAF3a-gaH07G-siGKeSkj13GQnOmjo/edit#bookmark=id.qztvoysscbtv">report</a>
for the finch.</td></td>
| The only explanation is maybe extension messaging clobbering user activation again. |
|
|
| Mac crash blink::Scrollbar::SetNeedsPaintInvaliation |
| |
| |
| liviutinta@ fixed a crash related to scrollbar on mac. |
<td><td>At first it looked like Scrollbar is used after free.</td></td>
<td><td>In reality, in some cases animation_ is released/deallocated in the
middle of the call to setCurrentProgress.</td></td>
<td><td>The solution was to keep animation alive during setCurrentProgress
by using Objective C retain/release.</td></td>
<td><td>This is the top 7th renderer crash on latest beta on mac. It is
responsible for 4 bugs (2 <a
href="https://bugs.chromium.org/p/chromium/issues/list?q=id%3A1183276%2C1189926%2C&can=1">P1</a>
release blockers, 2 <a
href="https://bugs.chromium.org/p/chromium/issues/list?q=id%3A1194276%2C1193025%2C&can=1">P2s</a>).</td></td>
|
| |
|
| Chapter IV: Interop fixes |
|
| |
|
| Created sticky demo for web.dev interop article |
| |
| flackr@ created a demo of one of the common remaining position sticky interop issues for the web.dev article https://web.dev/compact2021/ which was published this sprint. |
| Scroll-snap support for writing modes |
| |
| Old New |
| kevers@ worked on scroll-snap to enable support for writing modes. |
<td><td>The image on the left-hand side shows the old behavior where some of
the writing modes aren’t supported.</td></td>
<td><td>The image on the right-hand side shows that we now support all the
writing modes.</td></td>
|
|
| Scroll-snap outside of scroll corridors |
| |
| Old |
| |
| New |
| The missing block was offscreen in both x and y direction. Missed as a candidate search position when combining independent x & y searches. |
| Fixed tests in css/css-scroll-snap |
| |
| With the scroll-snap now support for writing mode and for snaps outside of the scroll corridor, a few tests has been fixed as shown in the above table. |
|
| |
|
|
| go/composite-relative-transform-finch |
| kevers@ worked on a document highlighting finch results for internal use only, the efforts includes |
<td><td>Communicated highlights in finch tracker bug with confidential bits
removed.</td></td>
<td><td>Two cleanup CLs: one to remove the GCL for experiment, and one to
remove the web feature flag.</td></td>
| Histograms for finger/pen drag distance |
| We need data for the ChromeOS proposal to allow bigger slop for pen taps. |
<td><td>The existing Event.TouchMaxDistance won’t work for us. Because it is
touch-only data, no data beyond slop rectangle.</td></td>
<td><td><a
href="https://chromium-review.googlesource.com/c/chromium/src/+/2779754">Added</a>
new histograms that splits distance-data into pointer-types. Specifically,
the histograms are Event.MaxDragDistance.{ERASER, FINGER, STYLUS}</td></td>
|
| |
|
| Chapter VI: Bug Updates |
| |
| Our team is seeing a recent spike in P1s, and we are working on addressing the issues. |
|
| |