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

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[me]

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.

Comment 1

[Daniel Holbert [:dholbert]]

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.)

Comment 2

[Daniel Holbert [:dholbert]]

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.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reproduces the problem in a debug build)

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.

Comment 4

[Daniel Holbert [:dholbert]]

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.