--- breadcrumbs: - - /teams - Teams - - /teams/animations - Animations Team - - /teams/animations/highlights-archive - Highlights Archive page_name: june-2020---web-animations-scroll-linked-animations-throughput-metrics-scroll-unification-webdriver-pointer-events-and-more title: June 2020 - Web Animations, Scroll-linked Animations, Throughput Metrics, Scroll unification, WebDriver, Pointer Events and more! ---

June 2020 | Chrome Interactions Highlights | Archives: go/interactions-team-highlights

| Fix transition retargeting | The CSS transition property is used to create a smooth transition of a CSS property on a style change. If the property is currently being animated (via an existing transition or other animations), this needs to be accounted for when calculating the starting point of the transition to avoid abrupt jumps in the value of the transitioned property. This process is called transition retargeting. We currently set the starting point based on the computed value from the last frame. | Our team members (kevers@ and gtsteel@) have made significant progress on this issue. Per spec, we need a base computed style (without animations) and then apply active animations on top of the base style to get the before style change for retargeting. Fortunately, the style resolver already tracks the base computed style (conditionally) in order to accelerate style recalculations that are driven purely by animation ticks. | Step 1: Add test cases for reversing modified transitions to WPT. | Step 2: Always cache the base computed style in the style resolver, tracking when it can be used for style recalc. Highlights: | Fewer flags to track | Fix storing the cached style on the first frame of an animation. | Reusable for transition retargeting | Step 3: Compute the “before change” style by playing active animations on top of the base computed style. |  |
| A better fps meter |  | xidachen@ has been working on measuring renderer’s smoothness and developed a better fps meter that reflects smoothness. This new-looking fps meter is available on canary. |  |  |  | Improved throughput UKM |  | In the last sprint, we changed the UKM reporting logic such that we report the median throughput of a page, which better reflects users’ browsing experience. Following graph shows the UKM curve where the red arrow points to the date when our change is landed. |  |  |  | Scroll-linked animations |  | flackr@ made a lot of progress and discussions on progress-based animations, particularly focused on procedure for converting time based animations. With this, developers won’t need to specify an arbitrary time duration for the animation: |  |  |  | Scroll unification |  | lanwei@ replaced eventsender with gpuBenchmarking.smoothScrollByXY (test list 12/62 remaining) |  | Unblocks scroll unification, because after we finish the scroll unification, the scrolls happens mainly on the compositor thread, and the scroll code in the main thread will be |  | removed. eventSender sends the scroll events to the main thread, so it would not work after the scroll unification. (Issue) |  | Tests full event delivery path |
|

WebDriver Actions Spec lanwei@ is adding wheel source type to the spec and associated WebDriver tests. In particular, the spec change pull request is here and design doc.

{"actions": \[ {"type": "wheel", "actions": \[ { "type": "scroll", "x": 0, "y": 0, "origin": element, "delta": 30, "direction": "y"} \] \] } Pointer Events altitude/azimuth attributes liviutinta@ sent a Pointer Events pull request to fix problems with default values for altitude/azimuth/tiltX/tiltY attributes. The associated CL by liviutinta@ is under review too. mustaq@ sent a follow-up pull request to fix boundary value conversion errors. The first pull request above adds important missing details to existing azimuth and altitude attributes: Support C++ code generation from pointer_event.idl and pointer_event_init.idl files. This was a blocker for C++ implementation in this CL. As a result the default values for tiltX, tiltY, azimuthAngle, altitudeAngle were removed from pointer_event_init.idl. This change allows one of the angle pairs to be specified in the PointerEvent constructor and the other pair will be automatically calculated by the user agent. Change the default value for altitudeAngle from 0 to /2 to better align with default values for tiltX and tiltY. Specify the rounding method when computing tiltX, tiltY from azimuthAngle, altitudeAngle Specify what happens when only some of the angle values are provided for untrusted pointer events: the user agent will never overwrite a value provided by the author even if the values are wrong. If the values provided for tiltX, tiltY, azimuthAngle, altitudeAngle are not consistent, it will be considered an authoring issue. Specify that for trusted pointer events the user agent will populate both sets of angles. Example specifying tiltX, tiltY in PointerEvent constructor and being able to use altitudeAngle, azimuthAngle afterwards.

var event = new PointerEvent("pointerdown", {tiltX:0, tiltY:45}); console.log(event.azimuthAngle); // will print the value Math.PI/2 console.log(event.altitudeAngle); // will print the value Math.PI/4 Example specifying azimuthAngle, altitudeAngle in PointerEvent constructor and being able to use tiltX, tiltY afterwards.

var event = new PointerEvent("pointerdown", {azimuthAngle:Math.PI, altitudeAngle:Math.PI/4}); console.log(event.tiltX); // will print the value -45 console.log(event.tiltY); // will print the value 0 Visual representation of azimuth and altitude for a pen here.

Chrome Interactions Highlights | June 2020 | go/interactions-team