| HN Mirror

Y	Hacker News new \| ask \| show \| jobs

by svnpenn 2397 days ago

Dont use site

Moving those sliders will nuke your CPU

probably because the entire <body> is essentially just:

    <script src="/prism.js"></script>
    <script src="/static/js/20.c80b9d97.chunk.js"></script>
    <script src="/static/js/main.635019b5.chunk.js"></script>
    <script src="https://d3js.org/d3.v5.min.js"></script>
    <script src="https://d3js.org/d3-array.v2.min.js"></script>

11 comments

wizzwizz4 2397 days ago

I don't like the architecture either, but this is one of the better sites using it that I've seen. It ran more smoothly than most non-interactive news sites, and the CPU usage was pretty much zero except when I was interacting with it.

What about your setup do you think might be causing this problem, given that very few other people are experiencing it?

link

irrational 2397 days ago

Hmm, I didn't notice anything on Firefox on my Mac. I have a ton of tabs open and about and 15 programs running, including handbrake rendering some videos. I opened up Activity Monitor and watched what happened while loading and then manipulating the sliders. Nothing. Absolutely nothing budged under CPU, GPU, or Memory. The site was smooth as a hot knife through butter.

Maybe you should list your OS, your browser, and your hardware specs.

link

tyingq 2397 days ago

It runs fine on my crap Motorola Android. So, something is afoot with GPs device.

link

40four 2397 days ago

I also experienced performance issues when using the sliders. My whole computer acted like it was going to freeze (Firefox/ Windows)

link

oneeyedpigeon 2397 days ago

Works fine on my ageing iPad mini. What was it about those 5 scripts that you thought would cause a problem? What machine/browser are you using?

link

AceJohnny2 2397 days ago

No problem and smooth as butter in Firefox Windows.

link

devwastaken 2397 days ago

Works fine on Android Firefox. They should put in a debounce function on the sliders so it doesn't update as it's moving.

link

valine 2397 days ago

That would undermine the purpose of the site which is to help build an intuitive understanding of the svg viewport. There is educational value in having the graphic update while the slider moves.

link

sagebird 2397 days ago

There is nothing preventing setting a debounce function to update frequently. For example, why would you want to calculate updates more than 30 times a second, or why would you want multiple updates during a single animation frame ( ie update faster than the browser repaints)? Debouncing is an insurance policy against insane things that you don’t want to happen. A smart debounce function can even modify itself in response to how long an expensive function is taking on average for a particular device— to increase the debounce time if there is not sufficient time to complete one calculation before another begins. I’ll go as far to say that a properly tuned debounce function that is triggered on leading edge will, if anything, decrease perceptible lag, not add to it. It will also minimize (though not guarantee w/o additional mechanisms) out-of-sequence updates. Out of sequence updates can lead to janky/confusing behavior.

— edit: I see that I went off the deep-end, assuming that you were against using debounce functions in general. I now see that grandparent was conflating debouncing and not updating until slider comes to a stop. These are of course not the same thing. Apologies. I hope my comments on debouncing are useful to someone though.

link

baddox 2397 days ago

Presumably just listening to the slider state and updating some global variables is fast enough to not need throttling, but I would definitely update the SVG DOM inside a draw loop running in requestAnimationFrame since there's no point in doing it any faster than that anyway.

I'm not an expert on high-frame-rate web drawing, but I've played with it a fair amount, and AFAIK there's no need to do any fancy debouncing logic beyond requestAnimationFrame.

link

sagebird 2396 days ago

A need may arise if a calculation took longer than a frame. (I’ve encountered this making a little programming language that generates graphics that updates in real time as you type. I’d imagine similar issues with web based latex-> pdf generators that update the pdf as you type )

link

baddox 2396 days ago

If a calculation takes longer than a frame, then you’re going to stutter no matter what you do, right? I feel like the browser will do its best to let you interact with the slider between frames, but really I can’t think of a good way to have a smooth interactive UI with calculations that take more than a frame.

link

wattenberger 2396 days ago

ah, the joys of frontend web development!

I added a 30ms debounce, just to help out a bit. I'm seeing some serious jank in Firefox, which smells like the beginning of a rabbit hole. Hopefully I'll find some time to dig in there.

link

adamch 2397 days ago

Strange. I'm on a Macbook and this page nukes my CPU on FF Nightly, but not on Chrome.

link

bryanrasmussen 2397 days ago

FF Developer 71.0b10 MacBook Pro from mid 2018 running Mojave, works great.

link

Nullabillity 2397 days ago

Works fine for me on FF/Linux.

link

Mikhail_Edoshin 2397 days ago

Same problem here, had to restart the browser (Firefox/Windows). Ate all memory.