animate-css / animate.css

🍿 A cross-browser library of CSS animations. As easy to use as an easy thing.
https://animate.style/
Other
80.55k stars 16.23k forks source link

CPU Hogging with animate.css #114

Closed alixaxel closed 10 years ago

alixaxel commented 10 years ago

I'm developing a new website where I have a single element using the animated classes:

<div class="navbar-right hidden-xs">
    <p class="animated bounceInRight text-right">
        some dummy, short text
    </p>
</div>

I started noticing that whenever I opened my development or production URL, my laptop fan started speeding up like crazy. It took me a while to figure out that the CPU hogging was coming from this page. I then started tracing down all my jQuery code (which is not much, but it could be the origin since it does some list filtering on each keyUp event).

Even with all the Javascript disabled, the fan kept spinning - so, since this page was only loading Bootstrap and animate.css, I decided to comment out the animate.css CDN link from cdnJS:

//cdnjs.cloudflare.com/ajax/libs/animate.css/2.0/animate.min.css

To my surprise, the problem disappeared. Take a look at the following Task Manager screens from Chromium:

Sorry for blacklisting, but the tab title reveals the domain name for which I still haven't secured.

The first screen is with animate.css, and the second is with it commented out. The tab with the HAL favicon is my development (local) server and the other one is the production - however, the HTML is exactly the same.

Given that the bounceInRight animation doesn't repeat itself ad-infinitum, I find it very odd that the CPU usage is always in the 99-100% range. Is this a known issue/bug? Is animate.css even to blame, or is Chrome/Chromium?

daneden commented 10 years ago

That’s very weird. I haven’t done any testing relating to CPU usage because it hasn’t been a problem before. CSS animations in browsers that support them tap into hardware acceleration for CSS transforms & animation (exactly what bounceInRight and most other animations take full advantage of.)

This needs further investigation. What does Firefox (or any other CSS animation supporting browser) have to say about the same page on the same system?

alixaxel commented 10 years ago

Even weirder, I forgot to mention that those tabs also had one small custom CSS animation (not part of animate.css):

.animated.phase {
    -webkit-animation-name: phase;
    -webkit-animation-duration: 1.5s;
}

.navbar-brand .carret {
    -webkit-animation-iteration-count: infinite;
    padding: 0 0.1ex;
    color: #2d8585;
}

For the following HTML element:

<span class="carret animated phase">|</span>

I've opened both variations (with and without animate.css) on Firefox for like 5 minutes, and it seems copacetic so far (at least the fan is completely silent). I don't know how to inspect the resource usage on it though, but Ubuntu System Monitor is reporting 0% CPU usage on Firefox (when idle) - which is good...

eltonmesquita commented 10 years ago

Can you make a JSFiddle, a Codepen or anything that can show your code live? To me it looks like a bug in the browser or a problem related to an extension installed on it. Can you disable all the extensions in your browser? Also what's the version of Chromium and of your OS?

alixaxel commented 10 years ago

@eltonmesquita There really isn't much more to it: http://jsbin.com/axoBOce/1/edit?html,output.

Chromium v30.0.1599.114 on Ubuntu 12.04 LTS, hogging still persists with all the extensions disabled.

eltonmesquita commented 10 years ago

I've tested in Chromium 33 and I can't reproduce it. Can you try with a newer version like 33? Don't forget that Chromium is an experimental browser and has a lot of bugs. Chrome Canary should be your choice as it shouldn't have so many bugs.

daneden commented 10 years ago

This sounds more and more like an isolated issue. Closing if we don't see any similar cases soon.

On Nov 7, 2013, at 7:19 PM, Elton Mesquita notifications@github.com wrote:

I've tested in Chromium 33 and I can't reproduce it. Can you try with a newer version like 33? Don't forget that Chromium is an experimental browser and has a lot of bugs. Chrome Canary should be your choice as it shouldn't have so many bugs.

— Reply to this email directly or view it on GitHub.

daneden commented 10 years ago

Response here and on Twitter tells me this is an isolated issue. I know that’s a pain for you, @alixaxel, but you could try using a more recent version of Chromium or Chrome stable. Closing.

alixaxel commented 10 years ago

@daneden It's not that much of a big deal to me, I too suspect this is a Chromium fault.

@eltonmesquita Specifically to the jsBin, I've noticed the 100% CPU hogging only happens when you have 2 tabs (of the same bin) opened. Could you perhaps try duplicating the tab and see if the usage increases? @daneden Could you try that as well? Just for the sake of exhausting this remote possibility?

Update: Just tried my original dev and production designs, opening either one of them at a time doesn't result in a high CPU usage either. Sorry for not noticing this symptom before!

eltonmesquita commented 10 years ago

Yep, no spike here even with 15+ tabs of it. It's really an isolated issue.

kobbe0 commented 10 years ago

Hey!

Found a way to replicate problem!

Using Chrome 30.0.1599.101 on 2 computers and behaves exactly the same on both. Aslong as I have the tab in chrome open/active it is all fine. As soon as I switch to another tab so this one is in background CPU spikes to 100% (25% on quad core ofc). When I switch back the CPU (and fan speed) instantly drops to normal. Using the chromes built in task manager to see it. If I remove the animate/animated classes, the problem is gone.

I guess this is a bug in Chrome but maybe still intresting to investigate.

You can test it here: http://revoweb.no/cpu

Thanks :)

alixaxel commented 10 years ago

@kobbe0 Yup, I see that it here too.

kobbe0 commented 10 years ago

It works like it should in Chrome beta version.