the Chromium logo

The Chromium Projects

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
1</a>: Add test cases for reversing modified transitions to WPT.</td>

2</a>: Always cache the base computed style in the style resolver, tracking
when it can be used for style recalc. Highlights:</td>

    <td>Fewer flags to track</td>

    <td>Fix storing the cached style on the first frame of an

    <td>Reusable for transition retargeting</td>

3</a>: Compute the “before change” style by playing active animations on top
of the base computed style.</td>
<td>Support C++ code generation from pointer_event.idl and
pointer_event_init.idl files. This was a blocker for C++ implementation in
this <a
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. </td>

<td>Change the default value for altitudeAngle from 0 to /2 to better align
with default values for tiltX and tiltY.</td>

<td>Specify the rounding method when computing tiltX, tiltY from
azimuthAngle, altitudeAngle </td>

<td>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.</td>

<td>Specify that for trusted pointer events the user agent will populate
both sets of angles. </td>
image 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.
<td><td colspan=2>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</td></td>
<td><td colspan=2>Tests full event delivery path</td></td>
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. image 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. image 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: image Scroll unification lanwei@ replaced eventsender with gpuBenchmarking.smoothScrollByXY (test list 12/62 remaining) removed. eventSender sends the scroll events to the main thread, so it would not work after the scroll unification. (Issue)
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: 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