Bug 226321

Summary:

Animation FPS drops if SVG changes from becomes visible from opacity 0

Product:

WebKit

Reporter:

Roland Soos <roland>

Component:

Animations

Assignee:

Nobody <webkit-unassigned>

Status:

NEW ---

Severity:

Normal

CC:

dino, graouts, graouts, sabouhallawa, simon.fraser, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

Safari 14

Hardware:

iPhone / iPad

OS:

iOS 14

Attachments:

Description	Flags
Screen recording	none
Long paints in timeline	none

Description Roland Soos 2021-05-27 03:08:38 PDT

Created attachment 429862 [details]
Screen recording

Steps to reproduce:
1. Open https://smartslider3.com/bugs/webkit/opacity0dropfps/

Expected result: FPS should be consistent during the animation

Actual result: When the SVG becomes visible from opacity(opacity:0 and then in the next frame gets bigger than 0) cause the animation to feel sluggish as probably rendering of the resource allocate the main thread.


Workaround: use non-zero small opacity like 0.1 for starting point.

Able to reproduce:
iPad 14.5.1
iPhone 14.6

Comment 1 Roland Soos 2021-05-27 03:11:36 PDT

It's possible that not opacity:0 itself cause this issue as we add visiblity:hidden to the elements which has opacity:0. So the cause could be that visibility:hidden changes to visibility:visible.

[data-force-hidden], [data-force-hidden] * {
    visibility: hidden!important;
}

Comment 2 Alexey Proskuryakov 2021-05-27 18:15:09 PDT

I can reproduce on iPhone 12 Pro; animates smoothly on a Mac.

Comment 3 Simon Fraser (smfr) 2021-05-27 20:22:11 PDT

The SVG takes over 500ms to render on iPhone 7 Plus because of the filters (largely the gaussian blur). There's a layering change when opacity and/or transform transitions finish, which triggers a second paint of the SVG which is the visible stall.

Some `will-change:` should fix this. Or you could remove the filters, since (in this example at least) they don't do anything visible.

Comment 4 Radar WebKit Bug Importer 2021-05-27 20:29:09 PDT

<rdar://problem/78601603>

Comment 5 Roland Soos 2021-05-27 23:04:16 PDT

Thank you Simon, you are right. We dropped those filters and used filter="drop-shadow(...)" on the path and everything is the same.

What is the tool what you used to find that it takes 500ms to render that SVG? Is it a tool in Safari(Mac) what I could use during remote debug of the real device?

Comment 6 Simon Fraser (smfr) 2021-05-28 09:45:35 PDT

I used some internal instrumentation, but I think attaching with Web Inspector and collecting a timeline recording would show you some long paints.

Comment 7 Simon Fraser (smfr) 2021-05-28 13:05:24 PDT

Created attachment 430045 [details]
Long paints in timeline