[HN Gopher] Pointer Latency
___________________________________________________________________
Pointer Latency
Author : secondo
Score : 48 points
Date : 2020-04-25 19:51 UTC (3 hours ago)
(HTM) web link (rsms.me)
(TXT) w3m dump (rsms.me)
| modeless wrote:
| I've done a lot of work testing this type of latency in web
| browsers: https://google.github.io/latency-benchmark/
|
| On Windows, DWM's display compositing adds one frame of latency
| to every window on screen. It's not possible to render a dragged
| object in any window that sticks to the mouse cursor without at
| least one frame of latency.
|
| But when you drag whole windows around they _do_ stick to the
| mouse cursor with apparently zero frames of latency; how does DWM
| do it? Easy, they cheat by disabling the hardware mouse overlay
| during window dragging so that the mouse cursor gets that extra
| frame of latency too. You can prove this by enabling "Night
| light" in settings; watch the mouse cursor change colors as it
| transitions from hardware overlay to software rendering when you
| start dragging a window.
| skybrian wrote:
| If you try to "predict the present" based on the past (and when
| you use previous points to calculate velocity and acceleration,
| that's what you're doing) it will overshoot when there's a change
| in direction, and how much depends on how aggressively you try to
| extrapolate. For the one-dimensional case in signal processing,
| doing this with a quickly-changing signal like a square wave will
| result in ringing.
|
| It can smooth things a bit but it's not that good a substitute
| for actually improving latency.
|
| (There are probably consequences for coronavirus charts as well,
| since they're based on lagging data.)
| [deleted]
| xellisx wrote:
| Comment almost sounds like it's about PID.
| modeless wrote:
| Although I agree that there's no substitute for actually
| improving latency, I think it's possible to do significantly
| better at prediction. Mouse movements are not easily
| predictable but they are also not completely random; this is a
| good type of problem to apply machine learning to.
|
| Ultimately you want the lowest possible latency _and_
| prediction, because you can never get the latency to zero. Once
| the latency is small enough, prediction becomes a net win. For
| example, all VR devices do prediction for head and hand
| positions after lowering latency as much as possible elsewhere.
| benibela wrote:
| Reminds me of a Kalman filter
| snvzz wrote:
| The neglect for latency in current popular systems such as Linux
| sickens me.
|
| I suggest experimenting with cyclictest from rt-tests. On all
| hardware I've tried, I get 30ms+ peaks after running it on the
| background for not even very long. I can't comprehend how anybody
| could find this acceptable.
|
| I do run linux-rt for this reason. Then again, while linux-rt
| provides the tools to make latency reasonable, the rest of the
| system hardly does use them.
|
| As we move from the likes of Linux to better architected systems,
| potentially based on seL4, I do hope the responsiveness will
| return to sanity. Until then, I'll have to keep going back to my
| Amiga hardware as cope mechanism.
| joosters wrote:
| Why would a real-time OS help at all with latency? All RT means
| is that the latency can be reliably upper-bounded (but note
| that that upper bound might be very high/slow), it _doesn 't_
| mean that the latency will be reduced. Real-time OSs aren't
| _faster_.
| codys wrote:
| linux-rt is a patchset that changes the behavior of linux to
| increase the number of places where preemption can occur
| (among other things).
|
| Doing this decreases certain types of latency in certain
| situations. As an example, it tries to have interrupts
| disabled less frequently and for shorter intervals, and uses
| mutexes instead of spinlocks.
|
| As a result, using linux-rt can provide a lower latency
| experience compared plain linux.
| notriddle wrote:
| > I can't comprehend how anybody could find this acceptable.
|
| Because Linux is primarily funded by server companies, and
| servers are optimized almost exclusively for throughput?
| easytiger wrote:
| The jump in rhel from 6 to 7 basically made it incredibly hard
| to tune Linux for very low latency performance requirements.
| Fairly simple on 6 but 7 made it very difficult. There are lots
| of tools available, nohz etc, but it doesn't help much. Primary
| core on each numa node is also loaded with kernel threads
| causing huge amounts of jitter.
|
| Basically everything is tuned for running web apps with loads
| of procs for people who don't really care about latency of 100s
| of millis.
| benibela wrote:
| Apple 2e from 1983 was the quickest, it is said:
| https://danluu.com/input-lag/
| emersion wrote:
| >This happens in a buffer and is normally one display update
| behind in time.
|
| This assumes compositors perform their work right after each
| display refresh. Compositors can decide to perform their work
| later, some amount of time before the next display refresh (e.g.
| a few milliseconds). This allows to reduce latency because the
| new buffers submitted by clients (such as web browsers) can be
| displayed with less than 1 refresh period worth of latency. For
| instance the browser can update its buffer at last display
| refresh + 8ms, then the compositor can composite at last display
| refresh + 13ms, and the new frame can be displayed at last
| display refresh + 16ms.
|
| Here's for instance how Weston does it: [1]. Sway has a similar
| feature.
|
| >However since pointing with a cursor is such a core experience
| in these OS'es, the "screen compositor" usually have special code
| to draw the cursor on screen as late as possible--as close in
| time to an actual display refresh as possible--to be able to use
| the most recent position data from the input device driver.
|
| That's not entirely true. Nowadays all GPUs have a feature called
| "cursor plane". This allows the compositor to configure the
| cursor directly in the hardware and to avoid drawing it. So when
| the user just moves the mouse around the compositor doesn't need
| to redraw anything, all it needs to do is update the cursor
| position in the hardware registers.
|
| Compositors don't have code to draw the cursor as late as
| possible. Instead, they program the cursor position when drawing
| a new frame. (On some hardware this allows the compositor to
| "fixup" the cursor position in case some input events happen
| after drawing and before the display refresh.)
|
| But in the end, all of this doesn't really matter. What matters
| is that the app draws before the compositor draws, thus the
| compositor will have a more up-to-date cursor position.
|
| [1]: https://ppaalanen.blogspot.com/2015/02/weston-repaint-
| schedu...
| vxxzy wrote:
| I got a bit excited thinking this may go into latency of
| dereferencing pointers in C.
| sesuximo wrote:
| Same! I would love to read that
| rq1 wrote:
| It would be great to have these numbers indeed !
| gumby wrote:
| Yeah me too!
| forrestthewoods wrote:
| Same! I wrote a blog post that _kind of_ talks about that.
|
| https://www.forrestthewoods.com/blog/memory-bandwidth-napkin...
| deagle50 wrote:
| Interesting results. Any ideas why the L1 got slower?
| jcelerier wrote:
| > If you move your pointer left and right (or up and down) in
| sweeping motions and follow it with your eyes, you'll notice that
| the rectangle is trailing behind the pointer by quite a long
| distance
|
| that's definitely not what I am observing
| (https://streamable.com/9u4cpx). Enabling the predictive
| tracking, however, is quite nauseating especially in circular
| motions. Please don't play with your users' cursors !
| codys wrote:
| The article does mention that the predictive tracking feels
| worse:
|
| > predictive tracking will feel much worse than direct
| (technically lagging) tracking when there is no system cursors
| to match.
|
| Additionally, we can see the lag between the red box and your
| cursor in the video of your screen that you've uploaded.
|
| https://i.imgur.com/ZEBcGch.png
___________________________________________________________________
(page generated 2020-04-25 23:00 UTC)