In that sample the foreground scrolls perfectly smoothly for me, but the background looks jittery. This indicates to me that it's not a platform issue at all. That sample is just doing something weird with the background.

Yes, the background is odd but the foreground is definitely not smooth. I see small little jitters occasionally. At one point I had to wait 15 seconds for it to jitter, though.

Yes the back and foreground is quite jittery for me on Firefox, and I'm almost certain its the browsers own requestAnimationFrame that's the problem.

Update: Although, having a closer look at the scene, I see its pixel art, so I bet the author is snapping floating point positions to a pixel point to prevent sub pixel blurring.

Another small update: I was sure requestAnimationFrame was locked to 60fps, but I noticed on Chrome the other day it was 144hz, the full speed of my monitor.

yeah, http://canonical.org/~kragen/sw/dev3/qvaders is unplayable on 120-hertz monitors because i'm running the game physics from raf ;)

Also noting that it's choppy on iPhone, but it's really barely noticable. Cool little game!

thanks! the choppiness is for the same reason; if the frame rate drops temporarily due to cpu load or whatever, the vaders move slower

This jitteryness is because the sample doesn't have antialiasing enabled (since it's pixel art) and the background scrolling is 0.1pixels per frame, which means every 10 frames it snaps 1 pixel. The scrolling is also updating on fixed amount per frame instead of looking at deltaTime, so if there are lags or small differences in frame time this might look choppy.

But I think it's more meant to demonstrate drawing parallax layers rather than subpixel scrolling.

So by modifying it to look at delta time it would be smooth?

the answer to your last question is "inner platform effect" and "second system effect".

Because it's a surprisingly tricky topic on modern operating systems [1], and even trickier in web browsers (smooth scrolling was actually much easier to achieve on hard-realtime systems like the 8- and 16-bit home computers of the 80's and early 90s).

TL;DR: if you base your animation- or scroll-speed on the 'raw' measured time between two frames, you'll get micro-stutter because it's pretty much impossible to obtain a non-jittery frame duration on modern operating systems or web browsers, all you can do is try to remove the noise via filtering, or 'align' your measured frame duration with the display refresh interval, which on some platforms cannot be queried.

In web browsers the most important problem is that you can't measure the exact frame duration (which is fallout from Spectre/Meltdown), or obtain a precise 'presentation timestamp', or even query the display refresh frequency.

Even in the native OS APIs that provide a presentation timestamp (like DXGI on Windows or CVDisplayLink on macOS) that timestamp has considerable jitter and has not much to do with the actual presentation time when the frame becomes visible to the user.

And as soon as you base your animation timings on such a jittery timestamp you'll get micro-stutter (the easiest way to get smooth animation is actually to assume a fixed frame duration, but then your animation speed will be tied to the display refresh rate).

It's often possible to eliminate the timing jitter with 'noise removal' filters or just tracking an average over the last couple dozen frames, but those then may behave funny in situations where the frame duration changes drastically (such as moving a window between displays with different refresh rate, or when rendering stops and then resumes because the window or browser tab is fully obscured and then becomes visible again).

PS: Raylib's frame pacing code on the web is also a bit on the crude side [2].

...e.g. it just sleeps for 16 milliseconds, and relies on ASYNCIFY to enable a traditional render loop in browsers. It would actually be better to use a frame callback via requestAnimationFrame (or the Emscripten wrapper function emscripten_request_animation_frame), but this means giving up the cross-platform 'own the game loop' application model. Not that requestAnimationFrame alone solves any of the above mentioned time jitter problems though.

[1] https://medium.com/@alen.ladavac/the-elusive-frame-timing-16...

[2[ https://github.com/raysan5/raylib/blob/f1007554a0a8145060797...

Thanks for this comment, this thing you mentioned "micro stutter" is something that has had me really scratching my head in my game engine project!

Do you have any comment whether frame blending (actually using a mix of two frame states to produce the rendering) would be a workable solution?

https://github.com/ensisoft/detonator

This is a great answer, by the way. I know have better insight into what happens in these animation loops.