Summary: | Accelerated animations freeze on render tree rebuild | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Liam DeBeasi <ldebeasi> | ||||||||||||
Component: | Animations | Assignee: | Nobody <webkit-unassigned> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | commit-queue, dino, emilio, esprehn+autocc, ews-watchlist, glenn, graouts, koivisto, kondapallykalyan, niklasmerz, pdr, rniwa, simon.fraser, timdream, webkit-bug-importer, webkit, zalan | ||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||
Version: | Safari 12 | ||||||||||||||
Hardware: | All | ||||||||||||||
OS: | All | ||||||||||||||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=204805 https://bugs.webkit.org/show_bug.cgi?id=207359 |
||||||||||||||
Bug Depends on: | |||||||||||||||
Bug Blocks: | 148695 | ||||||||||||||
Attachments: |
|
Description
Liam DeBeasi
2019-08-22 12:47:00 PDT
I can add that this seems to be a regression. The same transitions work more smoothly on iOS 12.4 than on iOS 13. Created attachment 386084 [details]
Sample app shown on iOS 12
Created attachment 386085 [details]
Sample app on iOS 13
I just built a small sample with Ionic that shows why this bug is really bad for the UX. The same app runs on iOS 12 better and the animation is less stuttering.
That's why I think this might be a regression.
Sorry for the ping. This is really a huge UX flaw for page transitions in Ionic apps with certain pages. Can we do anything to get this fixed? Thanks (In reply to Niklas Merz from comment #5) > Sorry for the ping. This is really a huge UX flaw for page transitions in > Ionic apps with certain pages. I appreciate that you provided this detail. It allows us to priorities this bug better. > Can we do anything to get this fixed? It would be ideal if we had a minimum reproduction that doesn't rely on custom elements instead of https://codepen.io/liamdebeasi/pen/YzKNGzW but it's not a big deal. I can easily make a reduction myself. FWIW, I don't think I can work on it anytime soon due to other commitments. Having said that, it's probably not that hard to diagnose this issue even as the first WebKit bug for someone so if you can find someone who can work on this that might work too. (In reply to Ryosuke Niwa from comment #6) > It would be ideal if we had a minimum reproduction that doesn't rely on > custom elements instead of https://codepen.io/liamdebeasi/pen/YzKNGzW but > it's not a big deal. I can easily make a reduction myself. > > FWIW, I don't think I can work on it anytime soon due to other commitments. > Having said that, it's probably not that hard to diagnose this issue even as > the first WebKit bug for someone so if you can find someone who can work on > this that might work too. I can try and diagnose it a bit, though I am not very familiar with the WebKit code base. What kind of reproduction would be helpful here? The issue only happens with custom elements/Shadow DOM, so I am not sure that a reproduction without custom elements is possible here. Maybe the test case in bug 204805 can be helpful. *** Bug 204805 has been marked as a duplicate of this bug. *** 204805 has working WIP patch and test case without shadow trees. Created attachment 389514 [details]
patch
Comment on attachment 389514 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=389514&action=review > LayoutTests/webanimations/accelerated-animation-renderer-change.html:48 > + await new Promise(resolve => setTimeout(resolve, 50)); It would be preferable to get a reference to the animation using element.getAnimations() and then wait for its ready promise to resolve and then wait one frame using requestAnimationFrame(), that way there is no setTimeout() involved. > LayoutTests/webanimations/accelerated-animation-renderer-change.html:54 > + await new Promise(resolve => setTimeout(resolve, 500)); Ideally we could use requestAnimationFrame here too, possibly with 2 frames to guarantee the animation would have ticked a couple of times. Created attachment 389525 [details]
patch
Created attachment 389527 [details]
patch
Comment on attachment 389527 [details] patch Clearing flags on attachment: 389527 Committed r255663: <https://trac.webkit.org/changeset/255663> All reviewed patches have been landed. Closing bug. Adding slot based test in https://bugs.webkit.org/show_bug.cgi?id=207359 I just did a quick test with Safari Technology Preview on macOS and the latest iOS 13.4 Developer Beta 2. Looks like the issue is fixed and the patch has landed in the beta versions! The codepen works now and the page transitions in our app are much smoother! Thank you very much for fixing this. (In reply to Niklas Merz from comment #18) > I just did a quick test with Safari Technology Preview on macOS and the > latest iOS 13.4 Developer Beta 2. Looks like the issue is fixed and the > patch has landed in the beta versions! > > The codepen works now and the page transitions in our app are much smoother! Thanks for verifying that the bug is fixed! |