Page MenuHomePhabricator

browser.supportsAnimations() causes a forced layout
Closed, ResolvedPublic

Description

This function currently causes a forced layout, which makes the display of the DOM choppy. It's invoked soon after firstPaint, which is a time where a lot of stuff runs. It would be better for visual performance to either do it later or to just not do it at all. Since the line causing it is about doing feature detection, maybe there are alternative ways of testing for those browser features that doesn't cause a forced layout.

This article highlights a technique for detecting CSS animation support which seems like a much lighter technique than the one currently used by supportsAnimation: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Using_CSS_animations/Detecting_CSS_animation_support

I also suspect that the technique currently used might just not actually need getComputedStyle and could just read the style back, like it's done in that Mozilla article.

Event Timeline

Gilles created this task.May 15 2015, 9:53 AM
Gilles raised the priority of this task from to Needs Triage.
Gilles updated the task description. (Show Details)
Gilles added subscribers: Gilles, ori.
Restricted Application added a project: Readers-Web-Backlog. · View Herald TranscriptMay 15 2015, 9:53 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Florian renamed this task from browser.supportsAnimation() causes a forced layout to browser.supportsAnimations() causes a forced layout.May 15 2015, 3:30 PM
Florian set Security to None.
Florian added a subscriber: Florian.

I've looked at how modernizr does this and they use apply the style then read offsetLeft/offsetHeight which would also cause a forced layout. It seems that checking for 3d transforms specifically is what makes a read+write to the DOM necessary.

Does mobile web actually need 3d CSS transforms and not just more basic CSS transforms?

Grepping through the MobileFrontend code, translate3d is used in a few places, but the z axis parameter is always 0. I think these could be replaced by regular 2d transforms, meaning that supportsAnimations can do a much simpler test to verify that the browser is capable of CSS 2d transforms, transitions and animations.

Gilles claimed this task.May 18 2015, 2:26 PM

Change 211728 had a related patch set uploaded (by Gilles):
Simplify CSS animations feature detection

https://gerrit.wikimedia.org/r/211728

@Gilles see my comment on the patchset. Your patchset makes animations choppier when they actually spring into action. Please reply on this bug if you disagree (I tend to miss Gerrit notifications but always see Phabricator ones)

Change 211728 merged by jenkins-bot:
Simplify CSS animations feature detection

https://gerrit.wikimedia.org/r/211728

Jdlrobson closed this task as Resolved.May 24 2015, 8:39 AM