Nw.js: [BUG] CSS3 transitions & animations laggy on Mac retina

Created on 30 Jan 2015 · 23Comments · Source: nwjs/nw.js

Reproductible on Macbook Retina (end of 2013) with OS X Yosemite and latest nw.js 0.12-alpha2 (but i had the same issue with previous builds)

My tests
On the same computer Macbook Retina (end of 2013) with windows 8.1, Ubuntu 64bit and OS X Yosemite in multiboot
I tested the following simple snippet and I get the following results:

Windows: perfectly smooth
Ubuntu: perfectly smooth
OS X, nw.js 0.12.0: clearly laggy / stuttering
OS X, nw.js 0.12.0 with --ignore-gpu-blacklist: no changes
OS X, Chrome 41: nearly smooth
OS X, Chrome 41 with --ignore-gpu-blacklist: perfectly smooth

<!DOCTYPE html>
<html>
<style>
    body, html {
        width: 100%;
        height: 100%;
        padding: 0;
        margin: 0;
        background: #EEEEEE;
    }

    #div {
        position: absolute;
        width: 100%;
        height: 100%;
        left: 0;
        top: 0;
        background: #ff0000;
        opacity: 1;
        transition: all 400ms ease-in-out;
    }

    #div.on {
        width: 20%;
        height: 20%;
        left: 40%;
        top: 40%;
        background: #0000ff;
        opacity: 0.3;
    }
</style>
<body>
<div id="div"></div>
<script>
    document.body.onclick = function() {
        var div = document.getElementById("div");
        div.setAttribute("class", div.getAttribute("class") === "on" ? "off" : "on");
    };
</script>
</body>
</html>

Source

felicienfrancois

👍1

Most helpful comment

I've also noticed this behavior at chrome on retina screen.
I have external monitor (default LG) connected to my mac.
And I have page causing a lot of css transitions/animations. So this page looks smooth on my external screen, but once I move chrome tab to retina screen - performance decreases significantly, all transitions getting choppy :(

I believe that because of larger resolution, chrome needs to allocate more memory or something like that.

I have to note that Firefox doesn't behave this way, transitions looks smooth on both screens using FF.

NeXTs on 13 Oct 2017

👍4

All 23 comments

width, height, top, left etc are generally slow to animate as they cause layouting and repaints.
You should, if at all possible, use transform with translate and scale.

Resources:
http://csstriggers.com/
http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
http://jankfree.org/
http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/

klaemo on 31 Jan 2015

👍1

@klaemo Thank you for the tips but that's not the point.

The point is there is a big gap of performance between Chrome and NW.JS under mac OS X.

The snippet is just an example written to simply reproduce the issue with a noticeable enough lag but the laggy behavior also happen on a variety a situation

felicienfrancois on 1 Feb 2015

👍4

I think we have some problem with Chrome on MacOS and animations...
See this https://github.com/nwjs/nw.js/issues/3046

AndryBray on 1 Feb 2015

You can use translate3d(0, 0, 0) to force GPU to start working. but from your words it is not an issue.

askbeka on 1 Feb 2015

@klaemo @ITBeka
I just tried your two workarounds and I can notice positive changes for both of its.
But it's still a bit laggy and there is still noticeable difference in smoothness between NW.JS and Chrome.

The transform: translate3d(0,0,0) one seems a better workaround to me because it does not changes the behavior whereas scale/translate is not the same than animation on dimensions, especially when there are several block (accordion or whatever)

felicienfrancois on 2 Feb 2015

@AndryBray the issue you're talking about seems to be a chromium one and it seems almost resolved in latest versions.
There is maybe also an issue about the --disable-gpu-blacklist flag that seems not to be applied #1060

But the current issue is about the difference of performance between Chrome and NW.JS which is still present in the latest release (0.12-alpha2) and noticeable enough to create bad user experience (laggy/stuttering feeling)

felicienfrancois on 2 Feb 2015

I made some tests and I found the performance of NW.JS (0.12-alpha2) is similar to performance of Chrome (41) with setting Use hardware acceleration (when available) disabled.

felicienfrancois on 6 Feb 2015

Made some tests again with the same snippet and with --show-fps-counter

animation_bench

There is definitely an issue. The fps curve is regular on chrome even without --disable-gpu-blacklist, whereas there are serious troubles with NW.JS (same with and without --disable-gpu-blacklist)

Another strange difference between both fps meters is the mention of GPU raster status on Chrome. I had a look at chrome://gpu diagnostic pages:

Chrome 41
chrome_gpu_diag

Chrome 41 (--disable-gpu-blacklist)
chrome_dgb_gpu_diag

NW.JS 0.12-alpha2
nw_gpu_diag

NW.JS 0.12-alpha2 (--disable-gpu-blacklist)
nw_dgb_gpu_diag

The issue seems to be related to rasterization.

felicienfrancois on 6 Feb 2015

This issue is still present in 0.12.0 and is quite annoying.
CSS transitions are not usable at all.

@rogerwang Have you any idea of what could be the issue ?
Is there anything I could do to help ?

felicienfrancois on 24 Mar 2015

Well it seems it is not fully related to css transitions but to retina display.

When I use jquery to animate I get the same issue.
When I set the Open in low resolutionflag it fix it all (fully smooth) but it also gets ugly :S

felicienfrancois on 24 Mar 2015

Another way to reproduce: Kaizou CSS Animation benchmark: http://www.kaizou.org/tools/kaizoumark/
I especially get very bad results with NWJS for Transform scale score:

NWJS 0.12.0 (Default flags, fullscreen)

Transforms: scale: 0 [Got 26fps instead of 30fps at complexity 1]
Transforms: scale (with opacity): 2 [Got 28fps instead of 30fps at complexity 3]

Chrome 41 (Default flags, fullscreen):

Transforms: scale:11[Got 17fps instead of 30fps at complexity 12]
Transforms: scale (with opacity):10[Got 22fps instead of 30fps at complexity 11]

IMPORTANT
Thoose performance issues are more noticeable when the window is fullscreen (or large enough).
In fullscreen mode any small and simple transition or animation will feel laggy in NWJS, even if it is local (like this benchmark)

felicienfrancois on 31 Mar 2015

:+1:

Just wanted to add that I have observed the same behaviour across platforms regardless of 'retina' or standard resolutions (it seems clear that higher resolution simply makes the issue more noticeable, hence the problems with full screen being reported). My project is currently stuck on v0.10.5 because of these performance regressions, and so a fix would be much appreciated.

jthrilly on 18 May 2015

And on that note....has anyone tested with v0.13-alpha? Does the situation persist?

jthrilly on 18 May 2015

Is it similar with #2723 which is just fixed?

rogerwang on 22 May 2015

Are you sure this is not a blink issue?

I'm experiencing the same on a website I'm working on in regular Chrome (beta and non beta). I was working on a regular 23'' monitor, and when I switched to the retina display of my macbook, animations started to stutter. I'm using CSS transforms btw.

PierBover on 19 Jul 2015

@PierBover this issue is about difference of performance between Chrome and NW.JS on the same machine, material and OS. So it is clearly a bug of NW.JS.

In your case it may not be an issue. The performance of animating and rendering on 2 different resolution is highly dependant on the resolution. If your 23' screen have a lower resolution than your retina one, it is normal to get a difference of performance

felicienfrancois on 20 Jul 2015

@felicienfrancois yes, but then I try the same website on Firefox on the retina display and the performance is smooth at 60 fps.

PierBover on 20 Jul 2015

I have this same problem. My lower resolution, external monitor is perfectly smooth. My retina display on my Macbook is so laggy that it is useless, and I'm using Chrome. I know it's not an issue of size because I have very little code - the site is just beginning. And there are only a few colors....anybody figure it out?

thecodercody on 20 Oct 2015

I no longer get any performance issue with latest 0.13.0
=> closing issue

felicienfrancois on 7 Jan 2016

I'm still having an issue with this.

maelswarm on 28 Sep 2017

I believe that because of larger resolution, chrome needs to allocate more memory or something like that.

I have to note that Firefox doesn't behave this way, transitions looks smooth on both screens using FF.

NeXTs on 13 Oct 2017

👍4

It was happening to me as well, but I ended up using the SVG image as a background image with css. I had to size the element with the right dimensions for it to work. Reason behind the right dimensions is that: If the 'no-repeat' property of the 'background' CSS property is used you'll hit the same performance issues.

Hope this works!

incubusknight on 20 Apr 2018

I am creating a slideshow and I have exactly this issue. I am using two different monitors (the one from the Macbook Pro and 24 as external). When I move to the external animation are very good. If I drag back to the retina it gets terrible. Any solutions? I am using CSS3 transitions incl. translated3d and so on.