Open Bug 811481 Opened 7 years ago Updated 7 years ago
Janky animation in CSSHat website
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.
At the extreme top & extreme bottom of this testcase's animation, Firefox (nightly) has noticeable snapping between pixels, whereas Opera smooths it out.
Attachment #681216 - Attachment description: testcase 1 → testcase 1 (animating translatey)
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.
You need to log in before you can comment on or make changes to this bug.