Bug 219751 - Efficient low frequency animations
Summary: Efficient low frequency animations
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Animations (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-12-10 11:44 PST by Jake Archibald
Modified: 2020-12-16 04:30 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jake Archibald 2020-12-10 11:44:26 PST
I did some research on how efficient browsers are at animations where not-a-lot happens.

https://static-misc-2.glitch.me/low-freq-anims/

I played with the above while monitoring the task manager.

The "High frequency animation" shows how much CPU is used on a 60hz (or whatever display frequency) animation.

"setTimeout" shows how much CPU is used for a setTimeout-driven animation that updates every 5 seconds. This uses almost no CPU.

The rest are CSS/web animations that update infrequently.

I'm _really_ impressed with how Safari handles these cases, but there are some opportunities for optimisation.

In the following tests:

- Discrete values
- Mostly same values
- Empty animation

…Safari seems to use more CPU than necessary, as if it's running a 60hz timer internally.

Related Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1157483
Comment 1 Simon Fraser (smfr) 2020-12-10 16:26:57 PST
Thanks for the info.

Our long-term objective is web-exposed API that allows devs to express what frame rate their animation needs.
Comment 2 Jake Archibald 2020-12-10 23:06:01 PST
Yeah, I think we need that too. I made some notes here https://github.com/whatwg/html/issues/5025 - seems important to allow multiple animations to exist on the same reduced frame rate timeline. I know you've thought about this more than me though, any API ideas?

However, I think the unoptimised cases in this test are still worth fixing.

Discrete - although a fixed frame rate would work here, it's already expressed in the animation keyframes.

Mostly same values - this can't be fixed by a reduced frame rate. I've used this style of animation for a "recording" indicator. Like, a red circle that briefly fades from opacity 0.6 to 1, then back to 0.6, then stays at 0.6 for a few seconds. The fading should be high frequency, but the browser shouldn't run a high frequency timer while values aren't changing.

Empty animation - this is an alternative to setTimeout but works with the document timeline timer, and doesn't tick when the document is hidden. I guess you could define this as a 0fps animation? But again this can be inferred.
Comment 3 Radar WebKit Bug Importer 2020-12-15 18:10:23 PST
<rdar://problem/72366315>
Comment 4 Antoine Quint 2020-12-16 04:30:45 PST
I had actually already planned to deal with discrete values, I'm still in the middle of implementing some remaining CSS properties for discrete animations.

Mostly same values… that'll require a bit more thinking.

Empty animations: that one's easy and I'll file a dedicated bug for this.

Note that for steps() we have dedicated logic already.