Choppy frame pacing with 60fps app on 60hz display (CPP / Windows / Neko / Hashlink)

[twilson90]

As long as I've been trying OpenFl/Lime, I've had issues getting consistent frame pacing.
I'm trying to get to the bottom of why this is happening and if it's an issue specific to my system (Windows 11, decent specs).

In my project.xml I simply have:

<window background="#FFFFFF" fps="60" vsync="true" />

When I compile a very simple program with some moving objects, targeting windows, neko or hashlink, it is very choppy, especially in windowed mode (fullscreen less so):

2026-01-26.19-29-36.mp4

In the bottom left I have a frame time graph (using Lib.getTimer()) and it doesn't represent what I'm seeing.

OpenFl has always been like this for me since first trying it years ago, so it's not a recent development. I don't know if there's just something consistently wrong in my configuration.
It doesn't matter how light/heavy the load is, visually it just seems to chug and it never looks smooth.

[ACrazyTown]

These seem related: #1569, openfl/openfl#2710, openfl/openfl#2594

I believe this is an issue with Lime's main loop, where the timing (done by SDL's timer) is only accurate up to 1ms. Because of this a frame is not dispatched every ~16.66ms (needed for 60fps), but rather every 16/17ms, which leads to the framerate inconsistencies.

BTW, unrelated, but your video isn't playable for me on Firefox. I had to open Chrome to be able to play it. Perhaps it's encoded weirdly or something?

[player-03]

BTW, unrelated, but your video isn't playable for me on Firefox. I had to open Chrome to be able to play it. Perhaps it's encoded weirdly or something?

Probably. It works fine for me in desktop Firefox, but it's a garbled mess on Android.

In the bottom left I have a frame time graph (using Lib.getTimer()) and it doesn't represent what I'm seeing.

I don't see the stuttering you're talking about, no matter how I play it. I've tried on a 59.96 hz and a 59.88 hz monitor, on desktop and on Android, in Firefox and in VLC.

I can almost convince myself there's a bit of choppiness on the rotating square between 1 and 2 seconds, but it's hard to spot. And the second rotation looks perfect, which doesn't fit the description of "never looking smooth."

For comparison, can you find a similar animation that doesn't look choppy, and post a video of that?

[twilson90]

Not sure why the video is having playback issues, works fine in Chrome for me. It's using the AVC codec but I guess OBS might be using a weird preset for lossless encoding.
Here's a version that should work better:

converted.mp4

I believe this is an issue with Lime's main loop, where the timing (done by SDL's timer) is only accurate up to 1ms. Because of this a frame is not dispatched every ~16.66ms (needed for 60fps), but rather every 16/17ms, which leads to the framerate inconsistencies.

I came across those issues before posting this, but it didn't seem like the same thing I'm experincing.

I don't see the stuttering you're talking about, no matter how I play it. I've tried on a 59.96 hz and a 59.88 hz monitor, on desktop and on Android, in Firefox and in VLC.

I can almost convince myself there's a bit of choppiness on the rotating square between 1 and 2 seconds, but it's hard to spot. And the second rotation looks perfect, which doesn't fit the description of "never looking smooth."

I guess some people are more sensitive to it than others. I work a lot with video and I can always tell when there's any kind of frame rate inconsistency. I've also noticed I'm usually the only one noticing them. As super powers go, it's not the most exciting.

If you go frame by frame in the video in MPV or your video player / video editor of choice, it's quite clear.
You should expect to see consistent movement of the rotating box with each frame. It happens in the first 3 seconds of the clip.

To save you the trouble I'll go through frame-by-frame and list the flaws...
[dup means it duplicates a frame]
[skip means it skips a frame]

32 (dup)
37 (dup)
46 (dup)
49 (dup)
51 (dup)
53 (skip)
54 (dup)
61 (dup)
64 (dup)
66 (skip)
68 (dup)
70 (dup)
75 (dup)
77 (dup)
79 (dup)
81 (dup)
83 (skip)
85 (dup)
90 (dup)
93 (dup)
97 (skip)
100 (dup)
103 (dup)
106 (dup)
109 (dup)
111 (dup)
115 (dup)
117 (dup)
120 (dup)
124 (dup)
...

I could carry on, it continues like that until around the 3 second mark (past 180 frames).

If you just consider these frames that I've listed, that's 30 bad frames out of 90.
If I let it record for a minute longer you would see occasional spikes of inconsistency (like in this example) along with a random smattering of duplicate / skipped frames happening all the time.
The entire time though, the frame time graph shows consistent flitting between 16/17 ms with occasional spikes of 18ms, but these frame time readings don't indicate what I'm seeing on the screen itself.

Having the mouse ontop of the window will make it worse, moving the mouse on the window makes it even worse.
It's not due to any hit-testing or the like, the frame time measurements (according to getTimer()) are quite consistent and do not reflect the mis-timed frames I'm seeing.
Moving focus to another window, the judder disappears for the most part, but I still see it do an occasional hiccup.
I should also stress, this is not a problem with the recording software, this is how it actually looks when I'm recording, and appears to be an accurate way of measuring the actual frame times as they appear on screen.

Curiously though, if instead of OBS's 'Screen Capture' I use 'Game Capture', the recorded clip will appear flawless, with not a single dup or skip. But what I'm seeing in the window of my demo app is a lot of judder.
So whatever hook OBS is using to grab the frame 60 times a second and encode it on-the-fly, appears to be doing a better job than Lime is at presenting it on the screen.

To my eyes it looks terrible and if I was to start building a game with OpenFl, fixing this would be my first priority (assuming it's fixable).

[joshtynjala]

I couldn't play the first video in Firefox on macOS, but the second video plays fine.

Playing at normal speed, I can definitely see that the rotation of object in the video appears much smoother after about 3 seconds, as described. The numeric ms value in the graph at the bottom right behaves a bit differently starting from that point too, as if it were rendered much more frequently. For the first three seconds, you see 16 and 17 much more distinctly for longer periods, but after 3 seconds, they blur together a bit.

[twilson90]

Here's a fun new example which demonstrates the frame timing issue a bit clearer without having to step frame-by-frame (features strobing so if you suffer from epilepsy probably don't play)

It's 60fps again, showing a rotating square that takes 2 seconds to do a full rotation, every frame it varies between a red and green fill. What you should see is a kind of muddy indistinct color, but you can clearly see the red and green distinctly when it chugs.

seizure.mp4

[dimensionscape]

Does it resolve when you enable vsync?

[twilson90]

This is all with vsync on. vysync off it makes no difference (except with added tearing in fullscreen mode).

[twilson90]

Sample code:

import openfl.display.Sprite;
import openfl.events.Event;
import openfl.Lib;

class FrameTimingTest extends Sprite {
	public function new() {
		super();

		var i = 0;
		var steps = 120;
		var spr = new Sprite();
		var g = spr.graphics;
		addChild(spr);

		function onEnterFrame(e:Event) {
			i++;
			var r = (i / steps) * 360;
			spr.rotation = r;
			var d = i % 2;
			g.clear();
			if (d == 0)
				g.beginFill(0xff0000);
			else
				g.beginFill(0x00ff00);

			var cx = Lib.current.stage.stageWidth / 2;
			var cy = Lib.current.stage.stageHeight / 2;
			spr.x = cx;
			spr.y = cy;
			g.drawRect(-300, -300, 600, 600);
		};
		addEventListener(Event.ENTER_FRAME, onEnterFrame);
	}
}

[dimensionscape]

Are you doing anything to create memory churn? Hxcpp implements STW GC, so any steep memory churn can cause noticeable stutters even with vsync enabled. Our current text implementation creates a lot of textures on dynamic text for every time it changes, which I see you have here. The garbage collector will stop all threads including the render thread during cleanup.

[twilson90]

There's no memory churn. The sample code I posted above (with no text elements) chugs just the same and nothing is happening besides 2 tris being rendered. No bitmaps. Default project.xml except 60fps.

I want to highlight again something I mentioned above which I think is important.
When I use 'Game Capture' in OBS to record the app, while the animation remains juddery in its window, the recording is a perfectly smooth 60fps with no judder.
I don't know how it works exactly, but the Game Capture method apparently sniffs which rendering lib is used (OpenGL, DirectX) and hooks into the internal frame buffer. Maybe because OBS is encoding video it's a bit more forgiving if a frame isn't quite ready, or the the frame is ready but for some reason OpenFl is a bit lazier in displaying it. I don't know. I have no idea how the backend works beyond the OpenGL renderer.

Also, the onEnterFrame loop also runs at an almost perfect 60fps if we trust getTimer() (despite the slight inaccuracy of SDL_GetTicks), so there is certainly no 'lag' in that sense.

When I put the app into fullscreen mode (alt+enter), after a flash of black and an initial judder it will also run flawlessly from that moment on. Unlike in windowed mode, mouse movement has no effect on frame times.
If I move focus away from the fullscreened app, then it gets really choppy.
Moving focus back to the fullscreened app, flawless again.
Going off-topic a bit - it's really annoying that toggling fullscreen there's a flash of black, not to mention the fact that moving the window or resizing it causes it to pause - but that's a separate issue for another day!

Sometimes I compile the exact same app and the judder is extremely frequent, other times less so.
It's random, sporadic and makes no sense.

I tried using OpenFl in the past (going back to 2017/18 or earlier). I would've been on Windows 10 and if memory serves, I noticed really bad frame time consistency back then with very simple demos when targeting Windows / Neko / Hashlink.

Am I the only one experiencing this? Does everyone just compile to HTML5 and Electron and so the problem has gone unseen / ignored for all these years?

[twilson90]

A new fun detail. Fullscreen, 60fps + vsync off I get this very consistent tearing effect. OBS cannot capture the fullscreen window in Screen Capture mode with vsync off, and other methods do not capture the tearing, so I recorded the screen with my phone @ 60fps.
Unfortunately the phone's camera adds a lot of its own weird artefacts, what you should concentrate on is the consistent waves of tearing happening. That isn't some weird camera / display rate mismatch, that is how it appears visually.

VID_20260128_134409.mp4

[joshtynjala]

Does everyone just compile to HTML5 and Electron and so the problem has gone unseen / ignored for all these years?

I test with neko and hl by default. Typically html5 only when I'm focused on an html5-specific issue. I don't usually enable vsync. The projects I work on have some animations, but the motion isn't usually at a continuous pace. Quick animations with easing, so maybe a bit harder to notice issues.

When I try your FrameTimingTest code, I can see the waves of tearing on Windows with vsync disabled, but not on macOS. However, macOS with vsync disabled looks juddery when rotating and shows distinct colors. vsync enabled on both rotates significantly more smoothly, and I see distinct colors occasionally, but more rarely than your video.

[joshtynjala]

If I disable vsync in Adobe AIR, it definitely gets juddery on both Windows and macOS. No waves of tearing, though.

#if flash
stage.addEventListener("vSyncStateChangeAvailability", (event:Event) -> {
	if (Reflect.field(event, "available") == true) {
		trace("disable vsync");
		Reflect.setField(stage, "vsyncEnabled", false);
	}
});
#end

Also requires <app swf-version="32"/> in project.xml.

[twilson90]

Do you also find it runs flawlessly in fullscreen (focused) with vsync on for neko, hashlink & windows?