Bug 185816
| Summary: | Run clip-path animations on the compositor | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jake Archibald <jaffathecake> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bfulgham, dino, simon.fraser, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 126207 | ||
Jake Archibald
http://output.jsbin.com/ticeve/quiet - this is a CSS animation. If you hit the 'jank' button (which causes the event loop to block), the reveal/hide part of the animation stutters.
It's common in UI for a transition to include scale/translation, but also some kind of revealing/hiding.
The former is easy to do entirely on the compositor, and avoid any kind of main thread jank, but the latter isn't.
You can kinda work around it by translating an element within an element that's overflow:hidden, but it gets complicated fast.
Ideally clip-path would work entirely on the compositor, and not jank like the demo page.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Simon Fraser (smfr)
Clip-path changes don't trigger repaints, but we don't run them in the compositor. I'd have to see how to map them to CoreAnimation APIs.
Brent Fulgham
Feature Request
Radar WebKit Bug Importer
<rdar://problem/97091889>