35 comments

[ 1.4 ms ] story [ 80.4 ms ] thread
Looks like the stargate icon
Really nice result, but there's one thing about it that really bugs me. http://imgur.com/KYQDTYD (Chrome on a Windows machine, if that's of any help).
Looks like that in Firefox on Linux too.
It's neat I guess but the edges are aliased.
This page uses close to 100% of one of my CPU cores. (Ubuntu/Chrome), not sure if it's because of the logo.
(comment deleted)
It might be the favicon, it's dynamically being altered and hammered by the JS.
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.
And this, gentlemen, is how you profile and debug problems.
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.

Same thing with MacOS/Safari.
(comment deleted)
It's a complete waste of CPU time.
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.

My /usr/bin/x process went from using 2% to 232%. Ubuntu 15.04 x64, Intel i7 3530QM @ 2.4GHz
Yeah, one of my Chrome tabs on OS X got really stuck too. Took half a minute to even close the tab...
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.
It looks like a capital lambda.
For the record Capital Lamda in Unicode: Λ

Unicode uses the spelling "lamda" in character names, instead of "lambda", but I could not find the reason for that.

"Lamda" is the modern pronunciation, while "lambda" is the ancient one, apparently. However, for the letters Μ and Ν they use the ancient Mu/Nu, instead of the modern Mi/Ni, so I fail to see the logic.
Do you pronounce mu as mee? Nu as nee? I've always heard them as mew and new in the US.

And what is the difference between lamda and lambda for pronunciation? I'd say them the same.

I also call them 'mew' and 'new' in English, but their modern names are 'mee' and 'nee'. I'm not sure what the ancient Greek pronunciation is, but I think that's where the 'ew' sound comes from.

The same goes for lambda. I use that in math & programming, but the letter Λ is actually called [lamða] in modern Greek ('ð' is the sound of 'th' in 'the'). That's apparently how 'lamda' is supposed to sound.

I was expecting one of those trendy HTML5 logo generators...
The logo is meh, but the grammatical error in the first sentence of TFA is obnoxious.
-1 for disabling zoom on mobile devices
Kudos to throw so much developing time on an ugly logo.
The resource / CPU requirements of this are not something to be proud of. If your logo means the rest of your site is going to take a serious performance hit, then your priorities are way off.
But why? Why would you dynamically render your logo like this? Is the extra overhead really necessary?