|
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><a
href="https://chromium-review.googlesource.com/c/chromium/src/+/2185509">Step
1</a>: Add test cases for reversing modified transitions to WPT.</td>
<td><a
href="https://chromium-review.googlesource.com/c/chromium/src/+/2252642">Step
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
animation.</td>
<td>Reusable for transition retargeting</td>
<td><a
href="https://chromium-review.googlesource.com/c/chromium/src/+/2220263">Step
3</a>: Compute the “before change” style by playing active animations on top
of the base computed style.</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. |
| |
| 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) |
<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>
| removed. eventSender sends the scroll events to the main thread, so it would not work after the scroll unification. (Issue) |
<td><td colspan=2>Tests full event delivery path</td></td>
|
| |
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: |
<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
href="https://chromium-review.googlesource.com/c/chromium/src/+/2165457">CL</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>
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. |