Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

In 1999, my DVD player could do this smoothly without any hitches or glitches. In 2020, my Xeon can't render this fast enough to avoid stutters. Either code quality has gone way down or my DVD player had a faster CPU.

View on HN

It's just a less-than-ideal implementation, your CPU is most definitely not suffering. Here is a completely smooth version:

https://codesandbox.io/s/nostalgic-cherry-wwpzj?file=/src/in...

(I made the exact same thing last year as a joke for our team monitors)

This is definitely not smooth on iOS, on a brand new iPhone that’s arguably way faster than whatever system played the original DVD screensaver.

On a technical note, not that there’s much you can do about this, but because you’re reading clientWidth and clientHeight each frame, you’re forcing reflow. A performant implementation would probably require avoiding the DOM altogether within the draw loop, so that would mean using canvas/webgl.

There are no elements in the page for style to be recalculated, so I doubt the reflow is what's slowing it down. I'm curious on what could cause bad performance for you though. It runs smoothly at 60fps on an iPhone 11 and the iPad, using Safari. Did you open the standalone page at https://wwpzj.csb.app/? My only guess would be that the CodeSandbox UI is too heavy for mobile.

For science, I went ahead and converted the code to ES3 and ran on the 10-year old first generation iPad (with setInterval) and it's still pretty smooth.

Not smooth here either. Can tell it wants to but will hiccup every now and then.

Looks great on my new iPad Pro, so I guess it was worth the money!

I have a 60fps + 144fps monitor setup and when I move it to my high refresh rate one, it goes hyperspeed :) You should calculate delta time with performance.now() and change position based off of that.

Haha, indeed. A correct implementation would calculate (pixel) movement speed based on a delta from last frame, left that out to simplify the code.

EDIT: I added a simple rate-limiting function :)

I tried it on my 120Hz monitor, looks great.

On my Chrome there are flashing scrollbars when logo hits right or bottom boundary.

No wonder modern frontend is such a mess.

I am sorry to say, but my MacBook Pro 2014 i7 is stuttering in Safari 11.1 on a 4k external screen.

It lags pretty bad on my Pixel phone too..

Only tested on an iPhone, works fine at 60fps. You can open the standalone page at https://wwpzj.csb.app/ to avoid the whole codesandbox app running at the same time.

I am grateful for your effort and have no intention to troll or diminish you - in case it looks like that. But still: now in desktop Chrome logo bounces from the very bottom or right edges of window, which is great, but there are gaps at the left and top edges, so logo never reaches those two edges.

I beleieve you are quite competent in this, so for me it's just another illustration of how HTML/DOM ecosystem is broken in so many ways that it takes enormous effort to perform such a trivial task. Thank you and plase stop wasting your time on this)

There are probably a dozen edge cases (!) that are not covered, though I bet most of them would be the same if using SDL or any other graphics engine. This was mostly a sample of canonical requestAnimationFrame use, in contrast to the original, and not an attempt to re-create the whole thing.

> Thank you and please stop wasting your time on this

Haha. Thanks. I like these mini-challenges, helps me relax for a few minutes :)

Yeah, it's not perfectly smooth for me (MBP 2019, Chrome).

I think adding `will-change: transform` might help a bit, to hint the user agent that you'll be animating transforms...

Firefox 74 on Windows 10, mostly smooth but stutters noticeably every few seconds.

Your computer is plenty fast, this is just written in a simple-but-slow way. See discussion under https://news.ycombinator.com/item?id=22882747

Its not the right tradeoff for everything, but this took 10 minutes to code and runs on practically every modern computer in existence.

Interestingly, it’s smooth as butter on 3 year old phone.

With these dedicated devices the engineers often were able to cut corners or use custom hardware.

This probably wasn't the case with DVD players (because the effort wouldn't have been worth it for a mass market consumer product) but 1980s Amiga home computers for example in some regard still outperformed mid-1990s PCs, which nominally were several orders of magnitude faster.

They were able to pull this off by clever hardware tricks and due to custom chips that were highly optimised for very specific use cases.

Run-of-the-mill PCs on the other hand were standardised and designed to perform good on average in most situations, not just very specific ones.

I'm a bit surprised and saddened by how literally this comment is being taken by replies. I think it's an apt comment, so I'll explain how I see it. My takeaway of the point is that we now live in an age of excessive abstractions. This is just a fun toy, so I don't want to be too critical of this case. But in other applications, excessive abstractions allow us to ship things that don't work, but look like they do. This fills the internet and our phones with garbage.

Because it was not coded with performance in mind. It updates the position left and top properties forcing the browser to re-render on each frame. What it should be doing is use CSS transforms so that only the GPU would be doing the updates.

Or use canvas and this won't be a matter of DOM manipulation.

Same here, it's not smooth on Firefox on my laptop. Some of the alternative implementations mentioned in this thread are somewhat better but I don't think any are consistently hitting 60FPS.

To be more specific about why the implementation is bad, it's hardcoded to refresh around every 30ms but not precisely 30ms.

Why is that bad?

"Code quality" is fine. This particular bit of code isn't written very effectively.

Interesting. Could you show me a Chromium implementation for your 1999 DVD? Since we're comparing apples to oranges here, it shouldn't be a problem.

Reply on news.ycombinator.com