Closed Bug 989075 Opened 8 years ago Closed 2 years ago

intial css transition on flex-basis is extremely janky, at Opera chapters demo

Categories

(Core :: Layout, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: me, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36

Steps to reproduce:

When using CSS transitions and flex-basis, the very first transition fails to smoothly progress. Subsequent transitions however are smooth as expected. Opening DevTools seems to mask the issue.

Here is a demo of the issue I'm referring to:
http://dev.opera.com/static/articles/2013/animating-flexboxes/flexbox-transition-js/flexbox-transition-javascript.html

Thus fare, I can only reproduce on Linux (Ubuntu 13.10). Win7 seems to be OK, not sure about OSX.


Actual results:

Initial transition does not animate. 


Expected results:

The initial transition animation should be as smooth as subsequent transitions.
I've been able to reproduce this sporadically.

When I do reproduce it, I sometimes see a few frames of the first animation, but it's just really janky. (And then subsequent transitions are much smoother.)

(Also, in case it's not obvious: to trigger the transitions on that page, you have to click one of the numbered chapter sections.)
Version: 28 Branch → Trunk
Status: UNCONFIRMED → NEW
Component: CSS Parsing and Computation → Layout
Ever confirmed: true
Summary: intiial css transitions on flex-basis not working → intial css transition on flex-basis is extremely janky, at Opera chapters demo
The URL from comment 0 is now gone, but the demo still exists at
 http://dev.opera.com/articles/animating-flexboxes-the-lowdown/transition-js/

ALSO: I noticed that I only seem to be able to hit the jankiness when I click *immediately* after the page loads.  If I instead wait a few seconds before I click, then the transition is smooth.
I can reproduce in a debug build with this testcase, by clicking one of the articles ASAP after the page loads.

I can't reproduce reliably with this testcase in a nightly build, presumably because the special startup-trigger-time goes by too fast.

Circling back to this, while retriaging flexbox perf bugs:

  • As of comment 3, this didn't affect Nightly builds anymore and seemed to only be observable in debug builds. So I tried to generate a performance profile in a debug build, but it's not cooperating. I do still sometimes see jank in my debug build when using this testcase, but I suspect that's more because of the the large repaint operations and other graphics-level things that aren't related to the reflow performance.

As support for that: here's a profile that I captured of two transitions, in a Nightly build, not-during-pageload (to just capture the incremental flexbox reflow behavior): https://share.firefox.dev/2YAxKsh

The reflow operations there (for each frame of the transition) are all less than 1ms long, so there's no sign of a perf issue there.

So I think there's no remaining flexbox performance issue here, and there also doesn't seem to be any significant performance issue at all that's observable in Nightly builds. So I think we can call this WORKSFORME - something/things must have addressed this, over the years.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.