LFC range 48Hz vs 60Hz?

[2mg]

Yes. It's a predictive algorithm that needs to take into account the frame times of previous frames and then predict what's gonna happen. If it was easy, every monitor would have it But it's not, and usually display vendors don't care much. And it's also the cost. It might require a faster scaler to run this algorithm instead of a cheap one.

Unless it's some kind of productivity monitor, or cheapest you can find for "it has a picture", these days it has VRR, usually the Freesync kind for the cheaper ones.

And even 1080p120 ones are pretty cheap.

Tho those maybe don't have variable OD, but then again how do you VRR at all, I've kinda skipped the early non-OD VRR screens.

Still don't know how you can predict rapid/unstable FPS change.
Unless you buffer 1 frame all the time, but the point of VRR is to have no tearing and low lag?

If you see two images there, then it's not a double-image effect. It's crosstalk.

It results in blur, not double-image. With sample-and-hold, the object stays visible at a fixed position while your eyes are moving. This creates a blur trail. The more times the same frame is repeated, the bigger the blur trail gets.

Sample-and-hold: blur
Strobing: double-image

They both have the same cause behind them: your eyes are moving while the screen only shows static frames.

Yeah I just tried this with PS1 emulation, since it's usually 30FPS (in 60FPS window, but irrelevant), Medievil game, since his running animation has a lot of jerky movement, with ShaderBeam.

Since it's 30FPS, on 240Hz, I can try 2, 4 and 8 subframes, Global refresh mode.

Indeed, if my eyes track anything, the less the subframes, the more the double images appear, and his movements become slightly harder to read even tho his position is static on the screen but he is never truly double-image'd.

8 subframes is flickerfest, but it's sharp and clear, aka no blur nor double frames.
4 subframes seems sharp but has double images, can't say I notice blur.
2 subframes I can tell it's blurry along with double images.

Haven't seen crosstalk tho, at least I think I didn't, so I fired up Mario quickly to check, when running and in the middle of the screen, no double images on his sprite.

Thanks for sending me down this hole

This popped a question in my mind - I know cinemas use(d) strobing and 24FPS.
Regardless if it's mechanical shutter, or digital BFI, how come people didn't complain about watching 24@48hz or 24@72hz?

[RealNC]

Still don't know how you can predict rapid/unstable FPS change.

Rapid spikes can't be predicted, but it doesn't matter because severe stutter is not gonna be helped any by having a good OD prediction. Whenever a game stutters/hitches (shader compilation, traversal stutter, whatever,) you're not seeing any ghosting to begin with because all you see is the stuttering, which is not perceived as motion anyway, but rather as a slideshow of images. For motion to be ghosting, you need to have something that you perceive as motion to start with

What can be predicted is where the frame rate is most likely going to be next by taking into account your average FPS of the last 100 frames or whatever the algorithm uses, and whether the graph is trending upwards/downwards or is flat. It's math and huge lookup tables for the colors and their corresponding voltages. Complicating it further is the need to use different voltages depending of what the previous color of a pixel was. If it's a simple g2g transition, things would be a bit easier, but we use color displays now, and thus a variable overdrive implementation gets really complex. I couldn't create one for sure, even though I do know math and am a dev. This requires some serious engineering.

This popped a question in my mind - I know cinemas use(d) strobing and 24FPS.
Regardless if it's mechanical shutter, or digital BFI, how come people didn't complain about watching 24@48hz or 24@72hz?

AFAIK, the standard strobe rate in cinema was 72Hz, so every frame was tripled. The triple-image effect didn't matter much because movies are shot using long camera exposure times to get as much "real" motion blur as possible, which masks the triple-image effect.

[2mg]

AFAIK, the standard strobe rate in cinema was 72Hz, so every frame was tripled. The triple-image effect didn't matter much because movies are shot using long camera exposure times to get as much "real" motion blur as possible, which masks the triple-image effect.

Could be.
Technically I can try a PS1 game with some camera exposure/blur shader and ShaderBeam.
Tho physical cinema shutters let light thru in a more of pseudo sample-and-hold way, the light starts going thru it top to bottom until the entire frame is visible which is immediately followed with a blanking part that covers the light top to bottom.

Anyway thanks for answering, I appreciate it!

[RealNC]

Tho physical cinema shutters let light thru in a more of pseudo sample-and-hold way, the light starts going thru it top to bottom until the entire frame is visible which is immediately followed with a blanking part that covers the light top to bottom.

In slow motion:

https://www.youtube.com/watch?v=3v9Y8iEN8Ck

And a slow motion of a super 8 projector's light shutter:

https://www.youtube.com/watch?v=DfBqIpkeRqA

[2mg]

In slow motion:

https://www.youtube.com/watch?v=3v9Y8iEN8Ck

And a slow motion of a super 8 projector's light shutter:

https://www.youtube.com/watch?v=DfBqIpkeRqA

Yeah, I've seen some similar videos - this thread's good for that viewtopic.php?t=253

User confirms that FPS=/=Hz mismatch causes double-image artifact and is present even in cinema if I understand correctly?
Should also affect modern cinema where probabl BFI or something similar is used?

[2mg]

The driver will choose when to LFC on its own. The 48Hz value is just a piece of info that limits the driver's decisions. It does not mandate that LFC has to be only used below that. It only tells the driver what the lower limit is. If the driver deems it better to LFC at 60Hz, it will do that.

I don't know of any configuration/tweak for the driver's LFC behavior. At 240Hz, I would probably set this to something higher than 60 anyway if you're playing a lot of 60FPS games so you're always LFCing to 160Hz or up. (So 80Hz.) This avoids LFC constantly activating and deactivating, which will produce flicker on some displays. 240/80=3, so it's plenty of range for the driver to use. The minimum ratio that's not recommended to go below is about 2.3 or so.

So I kinda did a thing unintentionally.

You know how I said in my original thread post that when at 240hz, LFC kicks in the moment I go below 60fps?

And why I can't use full VRR range (48hz minimum)?

Here's a video of that somehow happening (probably combination of alt+tab, fullscreen/window, Gsync in windowed apps, multiple apps in background, and app itself):
https://drive.google.com/file/d/1cj1c4G ... sp=sharing

That pulsing in that video is flicker when not heavily compressed by Google, hope it's visible enough, it's also not camera autoadjustment or something, it's flicker when viewed directly.

Tldr is that Dosbox, or the game in Dosbox, stops rendering if nothing is happening on screen.
This forces my screen's VRR into 49Hz, and you can see the flicker associated with that refresh rate.

It's slightly better when I move the mouse, but even that is not flicker-free and you can see it's trying to LFC in that case.

So why is this happening/why is it possible to "force VRR into submission"?


Note that this was done when in 240Hz refresh rate, I haven't tested 60@120 on this display yet, but I know 50@100 works but not 50@240, so I presume VRR has different min and max depending on what the current max refresh rate is?