pinafore icon indicating copy to clipboard operation
pinafore copied to clipboard

Content warning animation is low-framerate

Open nolanlawson opened this issue 7 years ago • 6 comments

This looks janky, especially on mobile Firefox. The built-in svelte-transitions slide animation animates height rather than transform.

nolanlawson avatar Apr 02 '18 07:04 nolanlawson

I think this can be closed, display: none seems to be used now.

sorin-davidoi avatar Apr 22 '19 19:04 sorin-davidoi

Yes this is about as fast as it can possibly get.

nolanlawson avatar May 02 '19 00:05 nolanlawson

Ah wait no, the issue is the animation itself. It animates properties that force style/layout, rather than ones that can run on the GPU (e.g. transform).

nolanlawson avatar May 02 '19 00:05 nolanlawson

I had a go at fixing this but I'm not sure how possible it is. The GPU-accelerated animation would require two things:

  • some way to clip the content as it slides down so that it doesn't appear "over" another element (I tried animating clip-path but sadly this isn't GPU accelerated in Chrome at least). There may be some z-index trick I can try.
  • every other element on the page that could possibly move would have to listen for slide events and animate itself. This seems really error-prone and gnarly.

So I'm not sure how practical it is to fix this. We could try switching to fade in/out animation, but I found it kind of ugly.

nolanlawson avatar Oct 11 '19 12:10 nolanlawson

If I understand correctly, the complication here is that transform can't be trivially used over height because you need the space to be reserved when in the expanded state (as normal static position/flow would) and given up to other elements before/after the current one when in the hidden state.

Assuming that's right, then using the FLIP principle might help.

The FLIP idea is: Use height during the setup of the animation (forced-computed via getBoundingClientRect, but never visually rendered), then leave height alone and let transform smoothly animate it from there. See more at https://aerotwist.com/blog/flip-your-animations/.

The main difference between this and plain height animation is that the space will be reserved at once and then taken up by the animation. If it is a design requirements that further elements move down pixel-by-pixel unison with the current element being expanded, then a non-janky implementation is pretty much impossible today. – For that, I think animating height is the simplest and most easy to reason about way to accomplish that.

Krinkle avatar Dec 31 '19 00:12 Krinkle

@Krinkle Thanks Krinkle, I'm aware of the FLIP method and I actually tried to implement this, but the additional problem is that there are multiple elements on the page that would need to move simultaneously, so each one would have to be FLIPed. I actually did implement this and then realized that I wasn't accounting for the border-bottom on statuses when you're replying to a toot and have to animate the reply box within a status (which should cause its border-bottom to animate down as well as every status below it).

I really need to write a blog post or something about how we need a new web API for this, because it's just way too difficult to implement manually.

nolanlawson avatar Jan 12 '20 17:01 nolanlawson