Prevent ripple effect from freezing during competing JS?

[ebidel]

When the effect is in motion, competing main page work (or navigation) freezes the canvas animation and prevents it from following through.

You can see this surface in a couple of places:

• http://youtu.be/Lbbu1W8vQWk
• http://googlewebcomponents.github.io/demos/google-youtube-video-wall/demo.html

Any ideas for a good workaround? Would an event at upAction time give users enough hook?

[morethanreal]

The ripple animation actually finishes some time after the up event. I can add an event that fires after the ripple completes, but I can think of a few problems:

1. It seems awkward to have to listen to some other event instead of tap or click to do something.
2. Is it good to introduce a delay before doing whatever the handler does?
3. This won't help with handling <a> elements since the browser handles it natively on the click event.

[ebidel]

I hear ya on the three points. No good solutions :(

We could introduce a delay before the handler kicks in, but we'd have to know if an element has an internal paper-ripple and conditionally apply the delay...as to not slow down all navigational clicks.

[robdodson]

This might be a use case for the noink button. Maybe the UX folks would
have an opinion

On Wed, Aug 6, 2014 at 2:57 AM, Eric Bidelman [email protected]
wrote:

I hear ya on the three points. No good solutions :(

We could introduce a delay before the handler kicks in, but we'd have to
know if an element has an internal paper-ripple and conditionally apply the
delay...as to not slow down all navigational clicks.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[ebidel]

I'm more worried that it makes polymer look janky, when it's no fault to Polymer. It's very easy to run into this by wrapping a paper-button in an anchor.

[robdodson]

I think that's true of any animation tied to an anchor. Maybe paper-button
should not use paper-ripple by default? What if you had to opt-in?

On Wed, Aug 6, 2014 at 8:33 AM, Eric Bidelman [email protected]
wrote:

I'm more worried that it makes polymer look janky, when it's no fault to
Polymer. It's very easy to run into this by wrapping a paper-button in an
anchor.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[IntranetFactory]

After wondering why our app feels sluggish I found that the ripple effect causes that "feeling" and then this issue. Did you already consider to use a CSS only ripple solution for paper-button, paper-icon-button like e.g. the approach used by http://publicis-indonesia.github.io/Waves/ ?

[robdodson]

I think we're still exploring ways to improve the ripple experience. The Waves site you linked to is really nice, thanks for passing that along!

[morethanreal]

We did some experiments and using transform appears to be more performant and there's some code in a branch that should land in the near future. However, I think this particular issue would still show up because regardless of how the animation is implemented, it'll get cut off when you navigate to a new URL.

[robdodson]

So if you're putting a paper element that has a ripple into an anchor, is the recommendation to include the noink attribute?

[IntranetFactory]

We're using a SPA - so we don't load another page. We have a paper item, when clicked another element is loaded and a slide animation is used to show the new element. In desktop chrome the ripple effect is still nearly smooth, but in IE11, Chrome on Android, and ios7 it's choppy and not smooth.

So for us the ripple effect seems to be only ok if no other animation starts - independently from navigating to another url.

[morethanreal]

Made some changes that may help with this.

• If any of the ripple's parents have the noink attribute, the ripple will not draw. That should help with the anchor case and any other case when the ripple is invisible after some action.
• The ripple now fires core-transitionend when it completes. You can listen for it if you want to wait for the ripple to complete before doing some action.

[IntranetFactory]

For me the new version didn't improve the behavior on ios, IE11 and Android Chrome. The only visible change is that in ios paper icon button now gets most of the time a quadratic background (and not a round one as before).

We start in all cases a CSS transition - and it seems that these transitions make the ripple effect choppy.

When delaying "our" animation until the ripple finished the ripple effect looks ok on IE11/ios/Android - but of course delays interaction. So better, but still not really perfect.

Firing core-transitionend to indicate that the ripple is finished makes it hard to distinguish the ripple from other transitions. Wouldn't it make more sense to name it like paper-rippleend?

[ebidel]

Another case from SO: http://stackoverflow.com/questions/26467902/polymer-how-to-render-template-asynchronous-without-affecting-interaction-with

[binoculars]

+1

[Godefroy83]

Hello, is there any solution to this problem?
it is really annoying and makes app unusable.

[illagrenan]

I have same problems with my Angular SPA navigation.

[MaKleSoft]

I wonder what the motivation is behind using a canvas for doing the ripple effect? Seems like immense overkill to me. Why not just use a gold old html element with a simple css animation? Currently the ripple effect on iOS is sluggish to the point where it is unusable.

[ebidel]

The implementation switching from canvas to css back in July: fba7a7e

[MaKleSoft]

Thanks, I missed that. Still, the animate function (and in fact the entire element logic) looks way more complicated than it needs to be. Maybe it's just ignorance on my side, but for instance, why do you use requestAnimationFrame to do the animation rather than a 'simple' css animation?

[beauwest]

I'm interested in a possible solution for this as well. My situation is not that it redirects the user to a new page, it's a single-page web app. The issue is that the competing JS causes the ripple animation to freeze.

It would be possible to just wait for the animation to complete, however, that's not optimal for the user. I'd rather present them with the information as quickly as possible and not introduce a unnecessary lag for them.

I realize that the issue isn't necessarily with paper-ripple, but suggestions for avoiding the jank would be very welcome!

[adaliszk]

I had the same issue as beaudesigns, I have a single page app and its ripple animation frezzing. In Timeline its littebit strange for me: After touchend it starting the Animation, Updating the tree (and paint), and it make 2-3 Hit test. What are thease hit tests? Also the "Updating layer tree" seems very long in the process, can we shring it some way?
Here my recorded timeline: http://a42server.net/polymer/TimelineRawData-20151030T155135.json