LastExceed wrote: ↑29 Dec 2020, 18:07
By "predicted position" I was referring to my prediction in the OP, not the hardware-cursor. The latter is even further behind everywhere except at the very top of the screen
Yes, got it. Just wanted to add the interesting software-ahead-of-hardware behavior.
LastExceed wrote: ↑29 Dec 2020, 18:07
Yes, that's exactly what I described in my prediction. I'm a bit confused about why you are reinterating this
My reply is for other Blur Busters readers too
As a courtesy to Blur Busters who often google and enter these forums at random threads, I like to add context for completeness' sake. I like sprinkling threads with relevant links, even if a bit redundant -- imagine being new to these forums but experienced in one aspect (VSYNC OFF tearline control, or raster interrupts, or hardware cursor weirdnesses), the links can be useful related reading.
If you know me around here, I am very classically verbose where possible (TMI techwise) on these advanced topics -- adding context for the sake of all thread readers...
LastExceed wrote: ↑29 Dec 2020, 18:07
Why Direct3D specifically ? As you can see OpenGL works too, and I'm pretty sure Vulkan and Metal would be no different either
It was just an example since it doesn't work when you try to write in higher level stuff (e.g. GUI languages, GDI, HTML5, WebGL, etc.).
But correct, any low-level OS API will work -- you just need to natively support VSYNC OFF as the quickest API-to-photons method, given the sequential serialization of 2D image data through a 1D cable to a panel on the other end of a display cable. As long as the API supports VSYNC OFF.
LastExceed wrote: ↑29 Dec 2020, 18:07
Eh, depends on what you call "ultra high". In theory, having your frame draw time just 1 mouse poll time (usually 1ms) shorter than monitor refresh time is all you need for a proof of concept under ideal circumstances, and I wouldn't exactly consider 53fps on a 50hz monitor "ultra fast"
Yes, this be true. Though for reliable human-visible software-ahead-of-hardware cursor behavior -- you ideally want a brute excess.
VSYNC OFF microstutters need to be kind of brute-forced out (microstutters are more visible at framerates only slightly above Hz), for the clear human vision effect. If you're doing measuring equipment/camera, it's another matter altogether (if you set up the variables sensitive enough). The clear human-visible distance-increasing behavior to appear as you move your mouse cursor around continuously near the top to bottom, like a circling the cursor -- with just your human vision, you see the distance between the hardware+software cursors more clearly vary as a linear relationship proportional to the distance of cursor away from the top/bottom edges of the screen -- this linear cursor-distance relationship versus Y axis value (distance between hardware vs software cursor continually varying), is much easier to human-eye-see if the microstutters are bruteforced out (via good excess framerate above Hz).
This weird clearly visible continual cursor-distance-varying (hardware-vs-software) behavior only occurs with VSYNC OFF, and never with VSYNC ON (a global scanout in sync with the global once-a-refresh mouse cursor compositing, either at driver level or hardware sprite level).
The fun-to-demonstrate cursor-distance-varying effect is also even easier to see at ultrahigh framerates during lower refresh rates (e.g. 1000fps at 60Hz), since the step distance of 60Hz is way huge, and the top-to-bottom is a continuum of that step distance. The more tearlines per refresh cycle, the more analog stepless the distance continuum becomes (mouse cursor smoothly visually steplessly converges to software=hardware as you reach top edge, and mouse cursor diverges software ahead of hardware, as cursor reaches bottom, to the full step distance of one 60Hz refresh cycle). If you have 16 tearlines per refresh cycle, and the mouse stepping is 16 pixels, the mouse cursor convergence occurs smoothly in 1 pixel increments as you move ~1/16ths screen height vertically, making the demo easy to human-see, when the microstutters are bruteforced out via sheer excess framerate far above Hz with many tearlines per refresh cycle.
The net result is as you circle your mouse cursor in a big circle on the screen, the software cursor clearly runs ahead of hardware cursor near bottom edge, and converges when near top edge. The way that the two cursors smoothly converges/diverges in realtime (as a function of Y axis) is fun to watch. A great demonstration of scanout latency [+0ms...+16ms] made easily human visible to the vast majority of population (instead of just esports athletes) .... in a "...Grandma, that's why esports athletes care about reducing input latency by 5ms..." easy EL15 demo that is human visible to just about anybody who has adequately functioning motion vision perception.
(Yes, if goal is electronic measurement rather than human-visible demos that most of population can see, then the brute is not necessary)
LastExceed wrote: ↑29 Dec 2020, 18:07
The irony about the FSE requirement is that it's false in theory, but true in practice. In theory there is nothing preventing this from working in windowed mode, but in practice almost every desktop environment of every OS uses a compositor that applies Vsync globally which can only be dodged by using FSE. As described at the end of the OP, I used a non-compositing window manager on linux to prove this theory as well.
Yes, this be true.
LastExceed wrote: ↑29 Dec 2020, 18:07
Speaking of Tearline Jedi, did you ever opensource the project in the end ? If yes, where can I find it ?
Not yet.
Reason: I am waiting for a co-author (or two) to collaborate with me with co-credits to do an Assembly.org submission (2021 or 2022) to exhibit this at some demoscene, before releasing to open source. There's a
pouet.net thread too. For a demoscene submission, the requirement is it can only go open source only after a demoscene submission. My idea of the workflow is to share private github and collaborators improve its cross platform compatibility while adding more beamraced demos to it, and then once good enough, submitted to Assembly. Was hoping to push ahead to it, but COVID and less business travel really put this off the 2020 radar.
