14 ms·

This is excellent. Too often people guess at things when they could be more empirical about them. Ever since I learned the scientific method (I think 3rd or 4th

• dralley 2y ago
  GNOME has unredirection support, so I don't think this test is applicable to actual in-game performance. A fullscreen app ought to be taking a fast path through / around the compositor.
  • deleted 2y ago
    [deleted]
  • eqvinox 2y ago
    This isn't about in-game performance, this is about the desktop feeling sluggish.
• AtlasBarfed 2y ago
  How old is Wayland? I'll be reading a dream of spring in my grave at this rate. I understand I'm complaining about free things, but this is a forced change for the worse for so long. Wayland adoption should have been predicated on a near universal superiority in all input and display requirements. Intel and AMD and Nvidia and Arm makers should be all in on a viable desktop Linux as a consortium. Governments should be doing the same because a secure Linux desktop is actually possible. It is the fastest path to showcasing their CPUs and 3d bling, advanced vector /computer hardware. Wayland simply came at a time to further the delay of the Linux desktop, at a time when Windows was attempting to kill Windows with its horrid tiles and Apple staunchly refused a half billion in extra market cap by offering osx on general x86.
  • dralley 2y ago
    Wayland is a protocol. The problems people complain about are generally implementation details specific to GNOME or KDE or (in general) one particular implementation. There's rarely any such thing as "universal superiority", usually you're making a tradeoff. In the case of X vs Wayland it's usually latency vs. tearing. Personally I'm happy with Wayland because there was a time when watching certain videos with certain media players on Linux was incredibly painful because of how blatant and obtrusive the tearing was. Watching the same video under Wayland worked fine. Early automobiles didn't have "universal superiority" to horses, but that wasn't an inhibitor to adoption.
    • bpfrh 2y ago
      I mean most of the things are the fault of a badly designed or non existent protocols: -Problems with non western input systems -Accessibility -Remote control(took around 2 years to be stable I think?) -Bad color management Then there's the things that did work in x11 but not in wayland: -Bad support for keymapping(the input library says keymapping should be implemented by the compositor, gnome says not in scope, so we have a regression) -bad nvidia support for the first two years? three years? While these things are compositor/hw vendor faults, the rush to use wayland and nearly every distro making it as default, forced major regressions and wayland kinda promised to improve the x11 based experience.
      • AtlasBarfed 2y ago
        Yes, and to the parents point it was a CHANGE in protocol. I get there was cruft in x. But the moment selected was a barrier to Linux desktop adoption precisely when the greatest opportunity in decades was present. And the desktop was reimplemented. Now in this period kde and gnome both decided to do rewrites, Ubuntu did their own desktop, got it up to snuff, and abandoned it. The lunacy wasn't just Wayland. If we are complaining the gnome compositor sucks... I mean , should that be the goddamn reference implementation? What percent of desktops are gnome, 80% at least? If the gnome composting ready for primetime, then Wayland isn't ready for primetime.
• arghwhat 2y ago
  Display devices (usually part of your GPU) still have "explicit display hardware just for the mouse" in form of cursor planes. Later this has been generalized as overlay planes. Planes can be updated and repositioned without redrawing the rest of the screen (the regular screen image is on the primary plane), so moving the cursor is just a case of committing the new plane position. The input latency introduced by GNOME's Mutter (the Wayland server used here) is likely simply a matter of their input sampling and commit timing strategy. Different servers have different strategies and priorities there, which can be good and bad. Wayland, which is a protocol, is not involved in the process of positioning regular cursors, so this is entirely display server internals and optimization. What happens on the protocol level is allowing clients to set the cursor image, and telling clients where the cursor is.
  • smallmancontrov 2y ago
    Protocols can bake in unfortunate performance implications simply by virtue of defining an interface that doesn't fit the shape needed for good performance. Furthermore, this tends to happen "by default" unless there is a strong voice for performance in the design process. Hopefully this general concern doesn't apply to Wayland and the "shape" you have described doesn't sound bad, but the devil is in the details.
    • jchw 2y ago
      Yeah, Wayland isn't designed in such a way that would require any additional latency on cursor updates. The Wayland protocols almost entirely regard how applications talk to the compositor, and don't really specify how the compositor handles input or output directly. So the pipeline from mouse input coming from evdev devices and then eventually going to DRM planes doesn't actually involve Wayland.
    • gizmo686 2y ago
      I don't think the Wayland protocol is actually involved in this. Wayland describes how clients communicate with the compositor. Neither the cursor, nor the mouse are a client, so no where in the path between moving the mouse and the cursor moving on screen is Wayland actually involved. The story is different for applications like games that hide the system cursor to display their own. In those cases, the client needs to receive mouse events from the compositor, then redraw the surface appropriately, all of which does go through Wayland.
• p_l 2y ago
  Hardware cursor is still a thing to this day on pretty much all platforms.
  • thayne 2y ago
    On sway, if you use the proprietary Nvidia drivers, it is often necessary to disable hardware cursors. I wonder if there is something similar happening here. Maybe wayland gnome doesn't use hardware cursors?
• giantrobot 2y ago
  > Wayland, being something relatively "new" compared to X11, has not had this level of scrutiny for as long. I'm looking forward to folks fixing it though. Part of the problem will doubtless be the USB (and Bluetooth) stacks including the device hardware and firmware. When keyboards and mice were serial devices with their own interrupt making the code path fast was achievable. I'm not so confident that modern peripheral stacks can be made to run with the same priority. It becomes even more challenging for devices sitting on a bus with multiple device classes or multiple protocols between the device and driver (USB -> Bluetooth -> Mouse). I hope devices can be sped up but we're a long way from a keypress triggering an interrupt and being handled in tens of milliseconds[0]. [0] https://danluu.com/input-lag/ https://danluu.com/input-lag/
  • ChuckMcM 2y ago
    As a systems I guy I completely agree with this. One of the things that was interesting about X11 is that it draws an API "wall" around the stuff involved in presentation. Many folks don't remember this but we had X "terminals" which was a computer system that did nothing else except render the screen and handle the input. In that compartmentalization there was nothing else competing for attention. You didn't get USB bus contention because there was just the one mouse, ever, on the line between the user and the X11 server in the X terminal.
  • ndiddy 2y ago
    The article you're commenting on is about someone running X11 and Wayland on the same computer with the same mouse and experiencing higher input latency on Wayland. I don't think differences between serial and USB mice are relevant here.
  • Permik 2y ago
    USB devices today are dummy fast, USB 3.1 signals at 10 GHz. You just need to check the USB queue more often :D Alternatively you move straight up to USB 4, where we get pci-e interrupts again! :)
    • hulitu 2y ago
• gf000 2y ago
  Asahi Lina's comment on the topic: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_edq7tn https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input...
  • hulitu 2y ago
    Tl;dr: X bad and tears but Wayland with 1.5 frame latency (or more) good. Now, if you have a monitor (or TV) with 30i refresh rate, you're screwed.
    • Vilian 2y ago
      1.5 is the worse case, and implementation specific
    • Edman274 2y ago
      We don't even know if it's actually a 1.5 frame latency for real because the test didn't try to establish that. The author said it looked like it was 1.5 frames, but that could be a coincidence. It just looks like a 1.5 frame overhead. It could, in reality, be a constant time overhead rather than a function of frames and so would be fine with a lower frame rate. Tearing would affect everyone that uses a computer with X11 but your proposed example of a TV with 30i refresh rate would only affect the tiny subset of users that use a CRT television as a monitor, right?
      • estebank 2y ago
        I don't think there was ever a 30i screen. GP probably meant 60 interlaced, which needs two full scans for a change, so an effective 30 full frames per second, but enough for 60 half images. For a Wayland compositor and the entire hardware stack would treat it as 30hz only if it really wanted to avoid interlace artifacts, but I don't recall that being a configuration that existed in my lifetime.
  • ChuckMcM 2y ago
    That is a great comment and everyone should read it. It also demonstrates a common truism that system goals dictate performance.
• paulryanrogers 2y ago
  Reminds me of how we used 'dir' command to test computer speed by watching how fast it would scroll by.
  • redmajor12 2y ago
    Or later, seeing how long it took to load /usr/bin in a filemanager.
• pengaru 2y ago
  Once upon a time XFree86 and Xorg updated the pointer directly in a SIGIO handler. But that's ancient history at this point, and nowadays I wouldn't expect Wayland and Xorg to have a hugely different situation in this area. IIRC it all started going downhill in Xorg when glamour appeared. After the cursor rendering path wasn't async-safe for execution from the signal handler (which something opengl-backed certainly wouldn't be), the latency was worse. I remember when even if your Linux box was thrashing your mouse pointer would stay responsive, and that was a reliable indicator of if the kernel was hung or not. If the pointer prematurely became unresponsive, it was because you were on an IDE/PATA host and needed to enable unmask irq w/hdparm. An unresponsive pointer in XFree86 was that useful of a signal that something was wrong or misconfigured... ah, the good old days.
• flohofwoe 2y ago
  > they sometimes had explicit display hardware for just the mouse because that would cut out the latency That's still the case. The mouse cursor is rendered with a sprite/overlay independent from the window composer swapchain, otherwise the lag would be very noticeable (at 60Hz at least). The trickery starts when dragging windows or icons around, because that makes the swapchain lag visible. Some window composers don't care any longer because a high refresh rate makes the lag not as visible (eg macOS) others (eg Windows I think) switch to a software mouse cursor while dragging.
  • Lanolderen 2y ago
    > The trickery starts when dragging windows or icons around Cool. Never really thought about why they don't exactly keep up with the cursor.
• babypuncher 2y ago
  This article only tests one compositor for Wayland and one for X11. It also doesn't specify if vsync is enabled for either one. Some X11 compositors default to vsync off, whereas every Wayland compositor I've seen defaults to on. This alone would be enough to explain the latency differences measured here. I like what's being done here but we need a more thorough experiment before we can start drawing conclusions.
• immibis 2y ago
  > Let me state up front that I have no idea why Wayland would have this additional latency It's not really hard to guess at - it's probably caused by abstraction layers resulting in multiple layers of buffering. Of course, it's all just speculation until proven by experiment, so good on TFA for doing some of that. Retro hardware from the C64 or NES era was single-tasking with such predictable timing you could change the video resolution partway through the screen refresh and have two resolutions on screen at once. If you want, you can check the player input and update Mario's position right before he gets scanned out - the minimum possible latency by design is zero frames. (Of course, in practice the whole screen data is buffered up during vblank, which is the same latency as using a framebuffer. Also the NES didn't allow changing video registers outside of blanking periods. But the C64 did.) X11 isn't that close to the metal, but it's designed with a single level of buffering (assuming a compositing window manager isn't used). There is a single framebuffer covering the whole screen. Framebuffer updates are completely asynchronous to scanout, so there is around 0.5 frames of latency on average between when a pixel is changed and when it's scanned out. Apps borrow pixels from this big global framebuffer to draw into. An app sends a "draw rectangle" command relative to its own borrowed space, and the server calculates where the rectangle should go on the screen, and draws it into the framebuffer, and then with an average latency of half a frame, that part of the framebuffer is scanned out to the screen. On Wayland, there are more layers. The app has to draw into its own pixel buffer (noting that it is probably double- or triple-buffered and has to redraw the entire window rather than relying on non-changing stuff to still be there) and then once the compositor receives the buffer from the app, it has to do the same thing again, copying all the per-app buffers into a big screen-size buffer, which is probably also double- or triple-buffered, and once the vblank hits, the most recent full frame is drawn to the screen. It's just more work with more layers, and there's no surprise that latency is higher. It's hardly the first or 100th time that an elegant software architecture resulted in the computer having to do more work for the sake of keeping the architecture pure. Something important to note is that tearing reduces latency. If new data is available while the scanout is partway through a frame, you have the choice to draw it immediately, causing tearing, or wait until the next frame, increasing latency. Always doing the high-latency thing is an explicit design goal of Wayland. (A third theoretical choice is to always time things precisely so that the new frame is calculated right before the end of vblank, but... in a modular multitasking architecture with apps written by different organizations and unpredictable CPU load, good luck with that.) Now the really big caveat: I'd be surprised if GNOME's X11 WM wasn't compositing. If it's compositing, then X11 behaves similarly to Wayland but with even more IPC and what I just said is no reason it should have one frame less latency on average. Still something to think about though.