Discorz wrote: ↑11 Sep 2021, 14:43
Since the ufo must be panned an integer number of
pixels per frame to look smooth, should these be the actual
pixel per second speeds?
Why doesn't TestUFO state actual speeds but only pixels per frame?
For informative purposes, I'll add an interim mouseover tooltip-style box that shows more statistics ("Target Pixels Per Second" vs "Actual Pixels Per Second") everytime someone mouseovers or clicks the PPF/PPS numbers. 960pps at 144Hz actually ends up being 1008 pixels per second (5% deviation) because of TestUFO's PPF priority behavior. This will provide useful information to TestUFO users.
Original Reason:
When TestUFO was first beta tested in year ~2012, the only refresh rates available were divisors of 60 -- and the VG278HE was released after the internal TestUFO beta was started.
(A) Pixels per frame is extremely useful as it often corresponds to the reference number of pixels of motion blur there should be for a ideal theoretical 0ms GtG sample-and-hold display).
(B) Fractional pixels per frame involves either blended motion (blurry pixels of subpixel position object) or jitter (stutter from rounding error), which adds an error margin to pursuit camera photographjy;
This way, it made it easier for MPRT-estimating-by-eye (for motion-testing experienced people) -- see link at bottom on how the UFO graphic was designed as a test pattern (before it became the Blur Busters corporate logo!). Going into a showroom or a convention of hundreds of displays, I can eyeball and visually estimate the MPRT to within one octave (e.g. MPRT 0.5ms, 1ms, 2ms, 4ms, 8ms, 16ms) even
just by glancing how the UFO degrades -- without always needing measuring equipment. Completely unmarred by the jitter/blur error margin of non-exact pixels per frame.
However, Motionspeeds Will Become More Flexible for 2022:
Yes, improvements are coming.
A change is being added to TestUFO next year to give more motionspeed flexibility, and better motionspeed calculations.
I agree that it should be more flexible, with accurately displayed calculations for odd refresh rates to eventually support all possible motion speeds (both integer and fractionals), with two modes of operation (subpixel rendering and snap-to-nearest-pixel rendering), including PPS-priority rendering and PPF-priority rendering modes.
The UX needs to be designed carefully without complicating the easy-mode TestUFO. Plus, the unified TestUFO rendering engine is integer-based, which means I have to edit dozens of source code files to refactor it to support both integer and floating-point operations. Needless to say, it's not a simple code change due to well-intentioned architecture decisions made a decade ago, partially due to the performance of the era didn't allow great subpixel rendering performance yet (at the time).
Some browsers did not even support subpixel rendering at the time, and I was the world's first website to recognize 2012's addition of VSYNC support to web browsers that made browsers usable for motion tests for the first time ever without needing to download an application. I also needed to support full frame rates on low performance Netbooks (Intel Atom!). And users who were using
<barf> MICROSOFT INTERNET EXPLORER </barf>. Thankfully, I am no longer constrained by any of these anymore!
This "Advanced Speed Settings" mode of TestUFO requires a significant rearchitecturing of the TestUFO engine, which may not occur until next year due to a physical move (both personal and business), so priority is supporting Blur Busters Approved clients (for now). The long term goal is to allow flexible custom motion speeds for all relevant speed-adjustable TestUFO tests, through a unified motionspeed configurator which may be hidden in a expandable panel (to hide complexity that only interests advanced users).
This minor deviation was scientifically chosen because there is
less error margin from a few-percent wrong speed, than from the extra blur (resulting from a scaling-style blur of subpixel rendering if rendering subpixelly, or as blurrier camera exposure of jitter blending into blur if rendering snap-to-pixel).
However, as refresh rates get higher and odder (e.g. 280Hz, 390Hz, etc) the error margin of this year 2012 decision is getting bigger and so there is an expanding need of more flexible motion speed to let the tester pick-preferred poison.
Nominally, it will be potentially simplified down to two hidden settings that appears only when selecting "Advanced..." in "Speed"
Custom Speed:
...Slider/Textbox: Exact motion speed (decimal point allowed)
Speed Preference Select:
...Round Off To Nearest Integer Pixels Per Frame
...Exact Motion Speed, Subpixel Rendered
...Exact Motion Speed, Jitter Allowed
Estimated Error Margin
Possibly with automatically displaying an automatically math-calculated error margin (it's calculatable!) for each of the 3 Speed Preference Selectors. Most of the time, the smallest blur error margin (relative to display's own true MPRT) will be the current default behavior of constant integer pixels per frame.
For non-integer-divisible:
Error margin for "Round Off To Nearest Integer Pixels Per Frame" would be the percentage difference of Target/Actual PPS speed.
Error margin for "Exact Motion Speed, Subpixel Rendered" would be the worst-case calculated scaling blur as a % of PPF
Error margin for "Exact Motion Speed, Jitter Allowed" would be the worst-case 1/PPF (1 pixel of jitter);
(Low frequency jitter visibly vibrates, while high-frequency jitter blends to additional motion blur)
For integer divisible:
Error margin is always 0 when PPS and PPF is exactly divisible integers (e.g. 960pps 4ppf 240Hz).
Behind The Scenes Article!
This article tells the scientific story of why 960 pixels per second was standardized:
Making Of: Why Are TestUFO Display Motion Tests 960 Pixels Per Second?