Why motion looks smoother on smaller screen?

[Berserker]

At native 1080p 144 and 120hz lightboost do not look as smooth as on CRT. When its on lower resolution with scaling disabled(so its small centered with black bars around) it looks much smoother with real-time feeling, same happens if I sit further from the screen.
Is it because eye tracking or some other reason?

[masterotaku]

When its on lower resolution with scaling disabled(so its small centered with black bars around) it looks much smoother with real-time feeling

Imagine this:
You are playing a 2D sidescroller at 1920x1080, 120fps@120Hz, and a tree crosses the screen from right to left in 2 seconds. That's 960 pixels/s, and every frame is 8 pixels away from the previous one. Without lightboost, that means 8 pixels of motion blur.

Now let's say you are using a 960x540 resolution without scaling (half the resolution per axis), and the same tree does the same thing, in 2 seconds. This time, it moves at 480 pixels/s, 4 pixels per frame, so you get 4 pixels of motion blur.

Proportionally it's the same ammount of motion blur compared to the size of the graphics (let's say the blur is 1/x the width of the tree), but you feel it as smoother because of the absolute ammount of motion blur, caused by the slower movement. The same thing can be said with lightboost on, but with a lot less motion blur.

same happens if I sit further from the screen.

Well, at a distance you may not be able to see the monitor resolution perfectly .

[Haste]

Not sure if that's a good theory, masterotaku. AFAIK Motion Blur doesn't make motion less smooth. On the contrary it helps make the motion less juddery.

[Chief Blur Buster]

At native 1080p 144 and 120hz lightboost do not look as smooth as on CRT. When its on lower resolution with scaling disabled(so its small centered with black bars around) it looks much smoother with real-time feeling, same happens if I sit further from the screen. Is it because eye tracking or some other reason?

Yes, relative angular eye tracking speed is related. However, there are additional factors.

1. Large screen CRT's at the same viewing distance and same refresh rate, has similiar fluidity behaviors (e.g. 100fps @ 100Hz at 24" away from a 24" screen, e.g. Sony GDM-W900 displaying 1920x1080 100Hz versus LightBoost monitor displaying 1920x1080 100Hz)

2. CRT clarity / LightBoost clarity can eliminate so much motion blur, that stutter are easier to see.

3. For the "CRT arcade-smooth effect", you must have frame rate == refresh rate == flicker rate == strobe rate for perfect smoothness simultaneously with full motion clarity.

So, for that, VSYNC ON 120fps @ 120Hz always look as beautifully smooth as CRT at frame rates matching refresh rate. The "60fps arcade feel" occurs only on LightBoost monitors only at 100fps@100Hz or at 120fps@120Hz. LightBoost is like a CRT that's stuck to running at only 100Hz through 120Hz, so you don't get many opportunities of matching framerate == refreshrate for the perfect CRT-smooth effect. Temporarily turn VSYNC ON (skip on worrying about input lag for a temporary moment; just during the test only), load up an older game that can always run at full framerate == refreshrate. If your graphics is powerful enough, this can be as recent as Bioshock Infinite (may need to reduce shadow detail two notches) or as old as Half Life. Sliding on the aerial rails in Bioshock Infinite feels much better during VSYNC ON LightBoost for example, if you can sustain 120fps@120Hz or 100fps@120Hz.

CRT's and LightBoost can be quite microstuttery/jittery during VSYNC OFF (and/or triple-buffered situations) especially during framerate-nonsynchronized situations as there's no motion blur to "smooth out" the microstutters. So during this situation, to reproduce the arcade-smooth effect, the Nintendo pan effect (e.g. Super Mario Brothers, Mortal Kombat), you need framerate==refreshrate.

Fun Factoid: Did you know almost all arcade games and NES games used the equivalent of VSYNC ON back in the 1980's, and we never complained about input lag? VSYNC ON only became evil during the 3D rendered framebuffered era when we needed buffers to render 3D graphics to, and introduced buffer layers (e.g. double buffering) that added extra input lag.

[Haste]

Chief,

something I've always wondered:

Isn't the peripheral vision more sensible to juddering than the central part of the vision?
I know already that the peripheral vision has a higher flicker fusion threshold. So is it true for the perception of judder as well?
Is there a correlation between the two? (flicker fusion threshold and perception of judder)

Btw is judder the right word for the concept of the lack of smoothness/fluidity?
Something tells me there must be a more appropriate word because judder is usually used to described the artifact caused by 3:2 pulldown.

[Chief Blur Buster]

Btw is judder the right word for the concept of the lack of smoothness/fluidity?
Something tells me there must be a more appropriate word because judder is usually used to described the artifact caused by 3:2 pulldown.

There's a lot of confusion between the word "judder" and "stutter", they are both used to describe unsmoothness of motion but in slightly different kinds of unsmooth motion. However, the word "stutter" is more common in the videogaming world, including other websites, so we'll continue to use that word for consistencys' sake.

Isn't the peripheral vision more sensible to juddering than the central part of the vision?
I know already that the peripheral vision has a higher flicker fusion threshold. So is it true for the perception of judder as well?
Is there a correlation between the two? (flicker fusion threshold and perception of judder)

There are separate factors occuring simultaneously.
Judder/stutter often creates a flickering-edge effect, which creates two simulatneous issues:

1. Edge-flickering caused by judder/stutter can be more sensitively detected by peripheral vision (at low frequencies, e.g. 12Hz judder cycle during 24fps)
2. Judder/stutter at high refresh rates essently blends to motion blur which is more sensitive by center vision. High-frequency stutter at, say e.g. 113fps@144Hz (and will even still happen at higher refresh rates, even 1279fps@1000Hz) if it was 8 pixel amplitude stutter, would blend into an 8 pixel motion blur. If the stutter is 5 pixel amplitude, it's a 5 pixel-wide motion blur if the stuttering is occuring at high frequencies beyond flicker fusion threshold.

Factor number (2) is very dominant on clear motion high-Hz displays including LightBoost. For example judder difference during mouse left/right panning (often less smooth) versus keyboard left/right panning (often smoother).

Also if you keep your eyes stationary while seeing motion (e.g. moving mouse in circles while staring stationary) you're actually seeing the stroboscopic effect rather than judder/stutter. An excellent thread that describe vision behaviors of motion is found in this thread, So what refresh rate do I need? [Analysis] [very good one!].

[Haste]

Btw is judder the right word for the concept of the lack of smoothness/fluidity?
Something tells me there must be a more appropriate word because judder is usually used to described the artifact caused by 3:2 pulldown.

There's a lot of confusion between the word "judder" and "stutter", they are both used to describe unsmoothness of motion but in slightly different kinds of unsmooth motion. However, the word "stutter" is more common in the videogaming world, including other websites, so we'll continue to use that word for consistencys' sake.

Ah, yes. Stuttering. That's the word I should have used.

2. Judder/stutter at high refresh rates essently blends to motion blur which is more sensitive by center vision. High-frequency stutter at, say e.g. 113fps@144Hz (and will even still happen at higher refresh rates, even 1279fps@1000Hz) if it was 8 pixel amplitude stutter, would blend into an 8 pixel motion blur. If the stutter is 5 pixel amplitude, it's a 5 pixel-wide motion blur if the stuttering is occuring at high frequencies beyond flicker fusion threshold.

Ah. That explains why on my CRT, I feel more motion blur at 100pfs@100Hz(v-sync) than 200fps@200Hz(v-sync). The lower temporal resolution of 100fps results in more motion blur than at 200. Even tho the persistence is the same in both case. Right?

What about the feeling of smoothness tho? I perceive benefits in that regard when using 200fps@200Hz even tho it's over my flicker fusion threshold.

I'm about to order a new computer, with decent horsepower. Once I'll have it running, I should be able to run some tests with various games and with the UFO. But for the time being take my observations with a grain of salt.

I am interested in learning and experimenting with the influence of temporal resolution on perceived smoothness.

Most information I read here, explains the benefits of higher refresh rates on motion blurring and imput lag. But I'm yet to find any info on the potential benefits on perceived smoothness.

[Chief Blur Buster]

Ah. That explains why on my CRT, I feel more motion blur at 100pfs@100Hz(v-sync) than 200fps@200Hz(v-sync). The lower temporal resolution of 100fps results in more motion blur than at 200. Even tho the persistence is the same in both case. Right?

Not necessarily, there are multiple different variables:
-- Beat frequency effects between mouse pollrate and display refreshrate, can be affecting things. You may be witnessing less mouse microstutters at 200Hz than at 100Hz. See Microstutter Mathematics.
-- Phosphor has some nonlinear behaviors. It can also be the excitation energy on the phosphor. Faster scanning (200Hz) means less time to excite the phosphor, which decays at different speed from a different excitation levels.
-- In addition, VSYNC ON can also have microstutters if you're not running perfectly synchronized. e.g. triple buffering microstutters.

Also, on the XL2720Z with the fixed firmware, strobe length is accurately adjustable fully independently of refresh rate, so motion blur is linked to strobe length rather than linked to refresh rate (As long as you run framerate == refreshrate). Stroboscopic effects (e.g. wagonwheel effect behaviors, mousedropping behaviors, more phantom array effects) at lower refresh rates than at higher refresh rates, which might be contributing to sensations of reduced motion clarity. See photographs of stroboscopic effect of 60Hz versus 120Hz. This isn't motion blur, however.

[Haste]

I see. There are so many factors involved that it's gonna be hard to isolate them one by one.

I'm looking forward to the release of the stand alone UFO application. Hopefully you can provide a perfect synchronization without any micro stutter. That way I can more easily test these things.

As for the stroboscopic effect when looking stationary at a moving object. I am well aware of it on my CRT.

[Chief Blur Buster]

I'm looking forward to the release of the stand alone UFO application.

I realize that web browser microstutters can be a problem, but designing synchronized motion tests in HTML5 that works on PC/Mac/iPad/iPhone/Windows Tablet, is much easier than creating multiple multiplatform applications. The HTML5, Animation Timing standard (end of Section 5 of http://www.w3.org/TR/animation-timing/ ) which I have been banging on web browser vendors to follow, now brings refreshrate-synchronization to HTML5 apps, so TestUFO works perfectly smooth on recent Apple iPads, for example. Conveniently, anyone in the world can post shareable links that instantly load a specific TestUFO animation. Something I can't do with a standalone app. But we realize not all systems can run browsers in a stutter-free manner. Especially Classic Mode on Windows 7 creates problems for TestUFO, for example. The best thing to do is essentially control browser microstutters by making Chrome your only application running, run only the TestUFO tab (no other browser tabs), and then also possibly give it higher priority (via Task Manager).

One idea I may do is create an application that runs as an embedded web browser (but running at real-time priority to eliminate microstutters caused by other running applications) to permit offline TestUFO tests (and more stutterfree), sometime in the future.