811481 - Janky animation in CSSHat website

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Zip of the CSSHat webpage

The animation at the top of the csshat.com index page is really choppy on the 11-10-2012 Nightly build (this is not a recent regression). It is very easy to see the images jump pixels while animating. The following is a discussion on #developers about this.

> <jaws> dholbert: do you know if we only interpolate to integer pixels? this animation here looks really choppy on gecko http://csshat.com/
> <dholbert> jaws, no, we interpolate more fine-grained than that (at an app-units level)
> <dholbert> jaws, but if each of those strings are having their position animated separately, it could be that different strings are snapping to different pixels at different times
> <jaws> dholbert: they're all images and using the same css animation
> <dholbert> jaws, ok, s/strings/images/ then
> <dholbert> jaws, I meant animated separately in the sense of "each of them are animated", rather than "they're in a parent element that is animated"
> <dholbert> s/are/is/
> <dholbert> jaws, that's part of why they're janky w.r.t. each other, I think... Not sure though. dbaron might have some thoughts. Likely worth filing a bug on
> <dholbert> jaws, if they all start off at exact-pixel-positions relative to each other, that shouldn't happen. If any of them is positioned between-pixels, though, that's the behavior we sort of expect
> <dholbert> because we'll reach the threshold to round up to the next pixel-position at different times
> <dholbert> jaws, (animation code does interpolate between pixels, but it has to snap to pixels to actually paint)
> <jaws> ok, because even without looking at them individually, their animation is kinda janky.
> <jaws> i checked and none of the images are started on half pixels, but they all might have different pixel distances between each other
> <bz> jaws: are you sure they're not started on partial pixels?
> <bz> jaws: how did you check that?
> <jaws> bz: looking at their stylesheet
> <jaws> will that not be enough?
> <bz> jaws: nope
> <jaws> getComputedStyle?
> <bz> jaws: getBoundingClientRect().top might be good enough
> <bz> jaws: maybe
> <bz> jaws: depending on whether the whole page is on an integer pixel or not
> <jaws> bz: i just checked with getBoundingClientRect().top and all are on integer pixels
> <jaws> (with the animation disabled)
> <jaws> so their initial position should be all on integer pixels
> <bz> jaws: ok

I've attached a zipped version of their webpage in case they change designs.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (animating translatey)

At the extreme top & extreme bottom of this testcase's animation, Firefox (nightly) has noticeable snapping between pixels, whereas Opera smooths it out.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (animating "top")

This testcase animates "top" in a relatively-positioned element, to achieve the same effect. In this testcase, opera is just as stuttery as Firefox.  (The same thing happens if I animate "margin-top", too)

So I think Opera's doing something special specifically for CSS transforms (w/ sub-pixel positioning -- I can see fuzzy light-blue edges as it animates), but they stutter as much as we do for other properties.

Comment 3

[Gregory Pappas [:gregp]]

Performs very well now.