Hacker News Reader

Comment by alipang | Hacker News Reader

This page uses close to 100% of one of my CPU cores. (Ubuntu/Chrome), not sure if it's because of the logo.

Looks like the page is spending an inordinate amount of time converting pixel data into a data URL. That's probably the favicon update then?

To find out, I took a process sample with OS X Activity Monitor. The main thread is spending most of its time in a requestAnimationFrame() callback, and about 77% of the work done there is inside toDataURL() calls.

Here's the relevant bits of the sample:

    +                   !   : |     +   773 WebCore::DisplayRefreshMonitor::displayDidRefresh()  (in WebCore) + 347  [0x10e41ac6b]

    +                   !   : |     +   ! 772 WebCore::ScriptedAnimationController::serviceScriptedAnimations(double)  (in WebCore) + 407  [0x10e4309c7]

    +                   !   : |     +   ! : 771 WebCore::JSRequestAnimationFrameCallback::handleEvent(double)  (in WebCore) + 240  [0x10e430dd0]

    +                   !   : |     +   ! : | 770 WebCore::JSCallbackData::invokeCallback(JSC::JSValue, JSC::MarkedArgumentBuffer&, bool*)  (in WebCore) + 598  [0x10e431146]

    +                   !   : |     +   ! : | + 770 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, JSC::JSValue*)  (in JavaScriptCore) + 63  [0x10dcefbaf]

    +                   !   : |     +   ! : | +   770 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)  (in JavaScriptCore) + 462  [0x10db1a0ce]

    +                   !   : |     +   ! : | +     770 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*)  (in JavaScriptCore) + 35  [0x10de565f3]

    +                   !   : |     +   ! : | +       770 callToJavaScript  (in JavaScriptCore) + 311  [0x10ded24a1]

    +                   !   : |     +   ! : | +         601 ???  (in <unknown binary>)  [0x4ab59b07e64d]

    +                   !   : |     +   ! : | +         ! 597 ???  (in <unknown binary>)  [0x4ab59b170afb]

    +                   !   : |     +   ! : | +         ! : 597 ???  (in <unknown binary>)  [0x4ab59b001034]

    +                   !   : |     +   ! : | +         ! :   597 WebCore::JSHTMLCanvasElement::toDataURL(JSC::ExecState*)  (in WebCore) + 180  [0x10e45a854]

An easy fix would be to throttle the favicon update down to a lower frame rate -- it doesn't need to be updated on every requestAnimationFrame() call.

Or they could just make it into a gif...

I think the problem is you can't control which frame is displayed at a given moment to keep it in sync with the page animation. It seems like there is only a finite amount of possibilities for the icon, so perhaps they should just cache the data URLs each time around and load them directly from memory, instead of drawing them, getting data url info, then setting it.

The animated Favicon doesn't seem to work on Firefox at all.

Also, CPU usage is also high with firefox, and according to the profile, over half of it is spent in GC.

Fun fact: If you open the logo on firefox, it'll show the shirked logo as a favicon: http://blog.arbitrary.io/content/images/2014/Mar/arbitrary_l...

It's a shame that gif favicons never made it back in the day. :(

This page (and worse, their home page) is unwatchable on my (not so new) phone as well, android 4.2.2 stock browser, probably still used by millions. Dear hipsters, form over function is terrible ux, throwing computational resources at a design problem does not solve anything.

Unrelated, but some time ago somebody redesigned medium.com to be so bloated I can't scroll half a line without terrible artifacts drawing themselves all over the text, on a website supposedly designed around the reading experience.

Yeah, one of my Chrome tabs on OS X got really stuck too. Took half a minute to even close the tab...

It might be the favicon, it's dynamically being altered and hammered by the JS.

Yep, same problem on Firefox 38/Ubuntu 12.04LTS x64. Its a lovely use of canvas though, I'm inspired to give it another go.

My /usr/bin/x process went from using 2% to 232%. Ubuntu 15.04 x64, Intel i7 3530QM @ 2.4GHz

It's a complete waste of CPU time.

Same with OSX/FF38

Same thing with MacOS/Safari.

Reply on news.ycombinator.com