[HN Gopher] Hard numbers in the Wayland vs. X11 input latency di...
___________________________________________________________________
Hard numbers in the Wayland vs. X11 input latency discussion
Author : todsacerdoti
Score : 323 points
Date : 2025-01-26 16:57 UTC (6 hours ago)
(HTM) web link (mort.coffee)
(TXT) w3m dump (mort.coffee)
| jchw wrote:
| Note that the results will differ between compositors, different
| GPUs, and different configurations. This is somewhat less the
| case with X11 since there is only one X server implementation
| (that Linux desktop systems use, anyhow.)
|
| I think there may still be the issue that many compositor/GPU
| combinations don't get hardware cursor planes, which would
| definitely cause a latency discrepancy like this.
| tapoxi wrote:
| This is probably compositor specific, so I wonder if this is a
| mutter issue or if it can be replicated in kwin.
| sapiogram wrote:
| Beautiful work. Could it be worth repeating the experiment with
| the monitor running at a very low refresh rate, i.e. 30hz? If
| Wayland is always a frame slower than X11, it should be much
| easier to observe.
| superkuh wrote:
| The various wayland compositors all have huge problems with
| keyboards, mice, and other input devices because the wayland spec
| and reference implementation(s) chose not to support such things.
| So each wayland compositor picks a different solution. Popular
| ones are libei and libinput but often there's just no support for
| "advanced" mouse/keyboard inputs at all (looking at you, weston).
| And you can never tell if a particular piece of linux software
| will work on any given wayland. The fragmentation is terrible. On
| X with the _strong_ X11 reference that actually implements
| everything you can be sure something that works on one will work
| on another.
|
| Hell, it's been 12 years and not a single wayland compositor
| supports screen readers for the visually disabled yet. They are
| toys.
| bsnnkv wrote:
| This is why I ultimately ended up on Windows after switching
| from macOS and focusing my free time development work on
| improving the power user/developer experience on Windows with a
| tiling window manager ecosystem.[1]
|
| One of the really cool things that has come out of this is
| seeing how people are adding accessibility workflows on top of
| the ecosystem. There is one person who controls their entire
| desktop via the tiling window manager using voice control![2]
|
| [1]: https://github.com/LGUG2Z/awesome-komorebi
|
| [2]: https://youtu.be/fiPJLmhnnXM
| BearOso wrote:
| Windows has added several things with the newer WDDMs to help
| alleviate compositor problems: flip model, overlays, etc.
| They've definitely identified the problem areas and are
| trying to correct them. It's been quite the turnaround since
| Vista.
| Hizonner wrote:
| I'm told they left out color calibration support, too (as I
| read it, there's no way for calibration apps to control, or
| even know, what compensation is applied when they're trying to
| measure things). Oh, and client side window decorations still
| around, giving up on the chance to fix an ancient security
| hole.
|
| So no good for games, no good for professional graphics, no
| good if you don't see well... basically no good if you're any
| different from the people who hacked it together.
|
| But, hey, with any luck they cut down on the screen tearing
| that I've never noticed.
| mariusor wrote:
| > basically no good if you're any different from the people
| who hacked it together.
|
| Why would you expect it any different? How can one implement
| things that they have no need or no hardware for? The
| entitlement is a bit jarring.
|
| Also I think they merged something last year:
| https://github.com/swaywm/sway/pull/7681
| Hizonner wrote:
| If you control what goes into a distribution, you can _not
| drop support for stuff that 's working and already
| implements those needs_ in favor of whatever you pull out
| of your butt.
| tuna74 wrote:
| You can do whatever you want if you control a
| distribution. Use something else if you don't like it.
| KerrAvon wrote:
| FWIW, I don't think they left it out so much as haven't spent
| the time to build it. It's not like they're pulling
| implementations off the shelf.
| mananaysiempre wrote:
| Color management support, though taking a long time, is
| moving along[1], and compositor implementations have recently
| started appearing. Device _calibration_ support is a
| different question, but a much more specialized one.
|
| [1] https://gitlab.freedesktop.org/wayland/wayland-
| protocols/-/m...
| jeroenhd wrote:
| It's unfortunate that colour calibration took a while to be
| fully implemented (xx-color-management-v4 landed on most
| compositors half a year ago I think, though LTS distros may
| need to wait longer to get it).
|
| That being said, thanks to Nvidia I never got colour
| calibration to work right in X11 either, so I have no horse
| in this race. Would be cool to finally get HDR working for
| the first time, but I don't know if that'll ever happen on
| Linux with Nvidia hardware. Guess I should keep dual booting
| for HDR content until either Windows 10 dies off or I get new
| hardware.
|
| I do actually notice the lack of tearing in Wayland,
| especially under heavy load. Used to annoy me to no end to
| see my windows tear when just dragging them across a 1080p
| screen. I don't know if it was an Intel driver bug (I tried
| all the config settings) or something X11 specific, but
| Wayland did finally fix the tearing issues I had.
|
| I haven't noticed any problems with colours in either Gnome
| or Gamescope (except for the lack of HDR, of course, but
| that's also true on X11) so whatever is causing issues for
| you seems to be DE specific. Looks like we both have issues
| other people never encountered, that's what makes graphics
| stacks so impossible to debug and code for.
| mariusor wrote:
| > there's just no support for "advanced" mouse/keyboard inputs
| at all
|
| It feels like you're probably blaming the wrong people here.
| You should look at the companies that make this peripherals
| that don't also offer you linux drivers.
| KerrAvon wrote:
| You say this, but have you seen the quality of the drivers
| they produce on platforms they ostensibly support? You do not
| want vendor mouse/keyboard software on any platform. Instead,
| improve the USB class drivers so that you don't need third-
| party drivers.
| jeroenhd wrote:
| I agree with you on general drivers, but what generic
| devices does Linux still lack? Controller HID support seems
| pretty universal, as do all manners of touch screens/touch
| pads, drawing tablets, and just about anything resembling a
| keyboard.
|
| The only hardware I know for sure is lacking is stuff like
| Stream Decks, but that kind of hardware is difficult to
| generalise for.
|
| Plus, most working hardware that doesn't fit a standard HID
| protocol already has drivers in the Linux kernel written by
| manufacturers.
| tuna74 wrote:
| What is lacking when you are using Orca on Gnome with wayland?
| henry700 wrote:
| Has implications for competitive FPS gaming on modern Linux --
| one more problem to fix. For example "The Finals" allows Linux
| players, but imagine having this much input delay and having to
| revert to classic x11 to play games, lol.
| riskable wrote:
| It's actually just cursor latency _specific to the windowed
| environment you 're running_. From what I've experienced (with
| a 4060 Ti) it doesn't seem to impact FPS games at all.
|
| I haven't tried any games that use a cursor with Wayland yet so
| I don't know if it would have an impact there.
|
| I think it has to do with whether or not the game in question
| is reading the mouse device directly (e.g. through SSL) or via
| the compositor. If it's reading the device directly it stands
| to reason that there would be less latency.
| rez9x wrote:
| I have trouble believing that 6.5ms in increased latency would
| be perceptible to any more than a fraction of a percent of the
| most elite gamers. Most the people claiming that this level of
| difference is impacting their gameplay are victims of
| confirmation bias.
| xyst wrote:
| You may think 6.5 ms of input latency is imperceptible. But
| combine it with the rest of the stack (monitor refresh rate,
| local network latency, RTT between client and server, time
| for server to register input from client and calculate
| "winner"), and it becomes the diff between an L and W. In the
| case of pros, the diff between a multimillion dollar cash
| prize and nil.
| sapiogram wrote:
| I would postulate that 100% of professional (i.e. elite)
| competitive gamers would be able to tell the difference. See
| this old touchscreen demonstration:
| https://www.youtube.com/watch?v=vOvQCPLkPt4
| Strilanc wrote:
| It doesn't need to be perceptible to cause a difference in a
| game.
|
| Suppose two players notice each other at the same time (e.g.
| as would naturally happen when walking around a corner in a
| shooter), first to shoot wins, and their total latencies are
| identical Gaussians with a standard deviation of 100ms. Then
| a 6.5ms reduction in latency is worth an additional 2.5%
| chance of winning the trade. Maybe you won't notice this on a
| moment by moment basis, but take statistics and its impact
| should be measurable.
|
| In ELO terms a 2.5% gain in win rate is around a 10 point
| increase (simplifying by assuming that single Gaussian is the
| entire game). That's small, but if you were a hardcore player
| and all it took to raise your ELO by 10 points was using a
| better monitor/mouse/OS... why not? Doing that is cheap
| compared to the time investment required to improve your ELO
| another 10 points with practice (unless you're just
| starting).
|
| Also, I think you'd be surprised what people can perceive in
| a context where they are practiced. Speed runners hit frame
| perfect tricks in 60FPS games. That's not _reaction time_ but
| it does intimately involve consistent control latency between
| practice and execution.
| pests wrote:
| Slightly off topic...
|
| > Suppose two players notice each other at the same time
| (e.g. as would naturally happen when walking around a
| corner in a shooter)
|
| This is not true for third person games. Depending on a
| left sided or right sided peek and your angle or approach,
| players see asymmetrically.
|
| For example, Fortnite is a right side peek game. Peeking
| right is safer than peeking left as less of your body is
| exposed before your camera turns the corner.
|
| I believe distance also plays a part in the angles.
| Strilanc wrote:
| Yeah, network latency and client side prediction and
| accuracy will also play huge roles. The actual
| distributions will be very complex, but in general
| reacting faster is going to be better.
| wink wrote:
| Do people not play deathmatches on LAN parties anymore
| these days? 2.5 is huge if the game lasts long enough that
| someone would be leading with 200. ;)
| cma wrote:
| There are noticability thresholds where this could push it
| over. For fighting games if you have the reactions to whiff
| punish N frame recovery moves this may push you to only being
| able to punish N+1 recovery moves and really impact your
| ranking. This is a little over 1/3rd of a 60hz frame.
| Hikikomori wrote:
| About the difference between 60hz and 120hz monitor,
| instantly noticeable just by moving the mouse in windows
| (just by looking at the distance cursor updates as it moves).
| Would you argue that all gaming monitors are placebo?
| layer8 wrote:
| Just to nitpick, that difference is still above 6.5 ms.
| bigstrat2003 wrote:
| I actually would. Gaming monitors are the equivalent of
| fancy audiophile gear. It's a way to fleece people by
| making them think they can perceive a difference that isn't
| really there.
| sapiogram wrote:
| But the difference between 60hz and 120hz is _instantly_
| noticeable in a blind test, without even opening a game.
| That 's by definition not placebo.
| tuna74 wrote:
| There have been actual tests showing players have better
| accuracy up to 360 fps displays.
|
| https://www.youtube.com/watch?v=OX31kZbAXsA
| Hikikomori wrote:
| Guess you think all speakers are the same.
| tolciho wrote:
| David Eagleman has done some work with drummers. Granted the
| audio system might be a bit more accurate than the visual, or
| maybe drummers are just weird. On the other hand, vim taking
| 30 milliseconds to start (ugh) and having sluggish cursor
| motions is why I'm on vi now. Haven't tried Wayland. Maybe in
| some number of years once it's more portable and more
| developed? (And how many years has it already been out?)
|
| > "I was working with Larry Mullen, Jr., on one of the U2
| albums," Eno told me. " 'All That You Don't Leave Behind,' or
| whatever it's called." Mullen was playing drums over a
| recording of the band and a click track--a computer-generated
| beat that was meant to keep all the overdubbed parts in
| synch. In this case, however, Mullen thought that the click
| track was slightly off: it was a fraction of a beat behind
| the rest of the band. "I said, 'No, that can't be so, Larry,'
| " Eno recalled. " 'We've all worked to that track, so it must
| be right.' But he said, 'Sorry, I just can't play to it.' "
|
| > Eno eventually adjusted the click to Mullen's satisfaction,
| but he was just humoring him. It was only later, after the
| drummer had left, that Eno checked the original track again
| and realized that Mullen was right: the click was off by six
| milliseconds. "The thing is," Eno told me, "when we were
| adjusting it I once had it two milliseconds to the wrong side
| of the beat, and he said, 'No, you've got to come back a
| bit.' Which I think is absolutely staggering."
| AnthonBerg wrote:
| Those sorts of latencies actually are noticeable! As an
| example, 6.5ms latency between a virtual instrument and its
| UI is _definitely_ noticeable.
|
| I didn't think it was. But it is. I promise!
|
| It's not necessarily a reaction-time game-winning thing. It's
| a feel.
|
| With virtual instruments, my experience is that when you get
| down to ~3ms you don't notice the latency anymore... but!,
| when you go below 3ms, it starts feeling more physically
| _real_.
| dralley wrote:
| As I type this, I'm playing "the finals" on Linux via Proton on
| Wayland. I won't pretend I'm any kind of competitive gamer
| type, but it's perfectly fine and I don't feel like I'm being
| held back by input lag. So this is very much a niche issue to
| have.
| talldayo wrote:
| "Competitive FPS gaming" stops allowing anything besides fresh
| Windows installs after a certain point. It's a diminutive
| distinction, like pointing out that emulating GameCube games
| won't let Smash Melee players fight competitively; nobody
| playing on either side actually cares.
| janice1999 wrote:
| > Has implications for competitive FPS gaming
|
| That has not been proven in the article. Input handling follows
| different paths for full screen games.
| sundarurfriend wrote:
| > having to revert to classic x11 to play games, lol.
|
| It would be more of a problem the other way around, if we had
| to resort to Wayland to get low latency. I think most of us
| using Linux for gaming and casual stuff are happy to stick to
| X11 for now and the foreseeable future. It has good support in
| software, its failure modes are well-documented, and it doesn't
| add one more layer to the pile of complexity that desktop linux
| already is; at least, not one us users have to consciously keep
| in mind as a common source of issues.
| dietr1ch wrote:
| On CS2 Wayland gave a major performance boost, but it's being
| held back by a regression since a change in device input layer.
|
| https://github.com/ValveSoftware/csgo-osx-linux/issues/3856
|
| From outside it's hard to tell if it's truly protocol
| differences or just the age of the implementations on X11, but
| when Wayland came out every project has claimed improvements
| over the old X11 stack. Also, from the early Wayland days
| presentations bashed the protocol as something that couldn't be
| fixed without a rework that was not going to happen due to the
| dead weight of backwards compatibility and awful older
| hardware.
|
| As a user applications running on Wayland have consistently
| improved on how nice things feel if you don't miss your latency
| deadlines. It's easy to perceive on apps, and straight out
| obvious in games.
| mikenew wrote:
| I get major lag spikes when the gpu is under heavy load (like
| doing Stable Diffusion inference or something). TBF I haven't A/B
| tested with X11, but I don't ever remember it being like that. An
| extra frame of latency isn't great on it's own, but the
| occasional spikes in lag are really irritating.
| cma wrote:
| May still happen especially if it is thrashing vram in and out
| of system memory or something, but have you tried lowering
| priority of the stable diffusion process?
| bigbones wrote:
| would love to see this test repeated with a non-compositing WM on
| X11
| sxp wrote:
| For anyone who uses ffmpeg for this type of per frame analysis,
| `ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true
| out%d.png` will get the "presentation time" of each frame in the
| video. That's more precise than just dumping frames and
| calculating timestamps. You can also do something similar in a
| web browser by playing a <video> and using
| `requestVideoFrameCallback()`. Though, you might need to set
| `.playbackRate` to a low value if the computer can't decode all
| the frames fast enough.
|
| > With my 144Hz screen,....Wayland, on average, has roughly 6.5ms
| more cursor latency than X11 on my system...Interestingly, the
| difference is very close to 1 full screen refresh. I don't know
| whether or not that's a coincidence.
|
| The fact that the latency is almost 1/144th of a second means
| that it might become 1/60th of a second on standard 60Hz
| monitors. This is hard to notice consciously without training,
| but most people can "feel" the difference even if they can't
| explain it.
| goalieca wrote:
| I found low latency terminals make a big improvement to even
| simple tasks like typing.
| daef wrote:
| what would you count as low latency terminal?
| layer8 wrote:
| See https://beuke.org/terminal-latency/. Single-digit
| milliseconds I'd say. These numbers are minus the keyboard
| and display latency.
| rustc wrote:
| Has anyone run this test on Ghostty?
| XorNot wrote:
| I was pretty shocked by the eyestrain difference I felt going
| from 30hz to 60hz with a 4K monitor while only doing coding
| tasks (i.e. text and mouse, no real graphics or animations).
| rcxdude wrote:
| It's almost certainly because of one extra frame of buffering
| between the mouse move and the screen. Vsync can cause this,
| but it should be possible to get vsync with just double
| buffering.
| mlyle wrote:
| > The fact that the latency is almost 1/144th of a second means
| that it might become 1/60th of a second on standard 60Hz
| monitors.
|
| My guess: the "true" numbers are close to 2.5 (half a frame of
| random phase of when the mouse is touched vs. refresh, plus 2
| frames to move cursor) and 3.5. If you throw out the low
| outlier from each set you get pretty close to that.
|
| (of course, the 125Hz mouse poll rate is another confound for
| many users, but this guy used a 1KHz mouse).
|
| > This is hard to notice consciously without training, but most
| people can "feel" the difference even if they can't explain it.
|
| Yah. 7ms difference is not bad vs 16.6ms is starting to be a
| lot.
|
| IMO, we should be putting in effort on computers to reach 1.6
| frames of latency -- half a frame of random phase, plus one
| frame, plus a little bit of processing time.
| mananaysiempre wrote:
| To have a compositor not introduce a frame of latency more or
| less requires it to race the beam, which has definitely been
| suggested[1], but you can see how it'd be difficult, and so
| far no operating systems have tried as far as I know. And as
| for good frame pacing support in UI toolkits (and not just
| game engines), well, one can dream. Until both of these are
| in place, 2.5+-0.5 seems to be the hard limit, the question
| here is more where the Mutter is losing another frame (which
| even the greats tell us[2] is not hard to do by accident).
|
| [1] https://raphlinus.github.io/ui/graphics/2020/09/13/compos
| ito...
|
| [2] http://number-
| none.com/blow/john_carmack_on_inlined_code.htm...
| amluto wrote:
| I've read these arguments quite a few times and always
| found them a bit questionable. Sure, if everything is
| driven by the vblank time (or any other clock that counts
| in frames), it makes sense. But that's a silly approach!
| There is nothing whatsoever special about allocating one
| full frame interval to the compositor to composite a frame
| -- if it takes 16ms to composite reliably, it will take
| 16ms to composite reliably at 30Hz or 60Hz or 144Hz. So
| shouldn't the system clock itself on a _time_ basis, not a
| frame basis?
|
| Put another way, a system fast enough to composite at 144Hz
| should be able to composite at 60Hz while only allocating
| 1/144 seconds to the compositor, which would require
| offsetting the presentation times as seen by the
| compositor's clients by some fraction of a frame time,
| which doesn't actually seem that bad.
|
| It gets even better if variable refresh rate / frame timing
| works well, because then frames don't drop even if some
| fraction of compositing operations are a bit too slow.
|
| I assume I'm missing some reason why this isn't done.
| sheepdestroyer wrote:
| It would be interesting to have numbers under gamescope instead,
| Gnome doesn't care much about gamers & power users that mesure
| latencies.
| dijit wrote:
| Games don't depend on a compositor for anything, they draw
| direct to the framebuffer.
|
| Anything related to the compositor won't affect the game,
| unless it's in windowed mode, then there can be some strange
| interactions.
| talldayo wrote:
| Games don't, but xWayland does.
| dijit wrote:
| I thought we were talking about gamers, xWayland doesn't
| affect gamers at all either.
| mort96 wrote:
| What do you mean? Most games run on XWayland when you're
| in a Wayland session, wouldn't input latency caused by
| XWayland therefore affect gamers who use Wayland?
| dijit wrote:
| Games don't run via X11, they write direct to the
| framebuffer using a framework like Vulkan.
|
| In windowed mode they can be captured, then things get
| tricky, but in full screen they draw direct to the gpu,
| vulkan itself is completely headless.
| sheepdestroyer wrote:
| I don't think that's true on modern platforms where the
| compositor (Mutter in the case of Gnome) is always
| responsible for presenting the frame.
|
| Gamescope's direct scanout bypasses this.
| dijit wrote:
| I'll look into it, but it used to be a choice in the game
| settings that bypassed the drawing display server
| entirely, and caused that full screen flicker you might
| recall when tabbing back to your desktop (and the
| switchover of rendering control, and subsequent huge
| performance loss of the running game).
|
| I wasn't aware that this changed, but you could be right.
| Its definitely the same on Windows as it always was,
| which is the platform I most developed games for.
| zokier wrote:
| > Its definitely the same on Windows as it always was,
| which is the platform I most developed games for.
|
| Not really. Most games use "borderless windowed" mode
| instead of fullscreen exclusive, and even FSE is not true
| exclusive mode anymore in most cases.
|
| https://devblogs.microsoft.com/directx/demystifying-full-
| scr...
|
| > When using Fullscreen Optimizations, your game believes
| that it is running in Fullscreen Exclusive, but behind
| the scenes, Windows has the game running in borderless
| windowed mode. When a game is run in borderless windowed
| mode, the game does not have full control of the display-
| that overarching control is given back to the Desktop
| Window Manager (DWM).
|
| see also https://learn.microsoft.com/en-
| us/windows/win32/direct3ddxgi...
| BearOso wrote:
| Most compositors can do direct scanout when they detect a
| full screen surface. (This is broken right now with Gnome
| on X11 because of the way window frames are drawn:
| https://gitlab.gnome.org/GNOME/mutter/-/issues/2794 ) If
| the game uses the platform cursor then that will reflect
| the additional latency, but the actual input signals
| won't be delayed.
| sheepdestroyer wrote:
| Valve's gamescope addresses something that you don't seem to
| believe exist :
|
| https://github.com/ValveSoftware/gamescope
| dijit wrote:
| That will indeed help with Windowed mode
| hirako2000 wrote:
| Was Wayland not architected to fix latency issues?
|
| I also find Wayland more laggy and more buggy without concrete
| evidence of course.
|
| It has significantly improved lately though, far more stable than
| it used to be.
| vander_elst wrote:
| Wayland is just a protocol that is probably implemented over
| and over and each implementation might have issues. It's mostly
| likely the different implementations having issues.
| hirako2000 wrote:
| Was Wayland not architected to be simpler to implement than
| the (antique) X11 protocol?
|
| Not arguing though, you are right it is just issues: Drivers,
| the Wayland implementations, how some plethora of apps and
| libraries have been battle tested then optimized, years over
| years, for X11. Not as much for Wayland display yet.
| KerrAvon wrote:
| Architecture contributes, but all it takes to blow input
| latency is some inefficient code almost anywhere in the
| input or rendering pipeline. The Apple IIe didn't really
| have very many layers between the keyboard and the CRT.
| Wayland might have an optimal architecture in theory for
| latency -- I don't know -- and latency could still be
| ruined by not fully optimizing the other components in the
| stack.
| mrweasel wrote:
| > Was Wayland not architected to be simpler to implement
| than the (antique) X11 protocol?
|
| I think it's safe to assume that it is actually simpler,
| given that we already have multiple Wayland
| implementations, but still basically just the one X11
| server implementation. Can one or more of those
| implementations shave off one or two milliseconds overs the
| next 40 years... Probably yes.
| somat wrote:
| Sure, on linux all you really have is xorg, what used to
| be xfree86, but I have used xsgi, and there are X servers
| for windows, heck, I have even seen this amazing demo
| Xserver that ran on the web.
|
| footnote: there is something wrong with the commonly used
| web search engines and I am unable to find that X11 web
| demo, I think they are prioritizing recent content over
| good content. you would think with how interesting that
| web demo was it was it would show up right away. but I
| got nothing, so no links. Anyway it was a deep dive into
| the intricacies of X11 window painting and the author had
| ported a limited subset of an X server to javascript in
| order to provide a live demonstration of the topic. I
| will keep looking.
|
| Found it.
| https://magcius.github.io/xplain/article/x-basics.html
| GuB-42 wrote:
| Wayland is simpler because it does less. And among the
| things Wayland doesn't do and X does are things that people
| need. It means these things have to be implemented
| elsewhere.
|
| It is a common problem with these "simple" things. The
| problem is complex, and if you simplify one part, you are
| just pushing complexity elsewhere, you are not making it
| disappear. It is sometimes a good thing, but in the case of
| Wayland, it didn't go well.
| freehorse wrote:
| There is also the option to make complexity disappear by
| just convincing people that they should not want to do
| what they want to do. This was the kind of response to
| what I needed to do. Then I had to switch back to x11.
|
| In any case wayland is not bad if you only have pretty
| basic needs I guess, some basic things look easier to me
| there from a user perspective, and troubleshooting
| x11-related issues for a non-technical person is no fun
| either.
| mixmastamyk wrote:
| Gnome was fixed a few years ago to remove significant latency
| it was adding. May have been a factor if you used that as well,
| but it wasn't wayland specific to my knowledge.
| itvision wrote:
| > Was Wayland not architected to fix latency issues?
|
| It was designed to fix tearing issues, not latency issues.
|
| But then the Wayland designers found out that players often
| prefer tearing to minimize latency, so the tearing protocol was
| implemented.
|
| When a committee of perfectionists, rather than real people or
| companies, design something, you often get something that is
| completely unusable by anyone but that committee.
|
| And that's exactly how it's played out so far. Wayland is still
| largely incomplete, not to mention it doesn't even have a
| reference implementation [1], and still doesn't
| include/describe several essential desktop APIs and features,
| which results in this protocol not having a ton of universal
| tools and applications that work across all of its
| implementations, including but not limited to:
| * Keyboard layout switching and input management *
| Display configuration * Clipboard management *
| Tools to manage windows/automate tasks * Lots more
|
| It's a damn ugly mess that has led to a lot of fragmentation
| with no obvious benefit. Currently, only KDE and Gnome have
| somewhat usable Wayland implementations. If you use anything
| else? You're SoL.
|
| 1. https://gitlab.freedesktop.org/wayland/wayland/-/issues/233
| tuna74 wrote:
| Of the things you list, IMO, maybe the display configuration
| should be part of the Wayland protocol.
|
| It might be a better technical design to have the other stuff
| outside of the display protocol. Just because Xorg
| implemented something does not mean you have to put it in the
| Wayland protocol.
| eschaton wrote:
| Routing of input events to windows has turned out to also
| be extremely important for a display subsystem in practice.
| It wasn't just X11 that did this, it was also the NeXT
| window server, and Sun's NeWS, and SGI's pre-X window
| system, and the original VAXstation window system on VMS,
| as well as how both modern macOS and modern iOS and iOS-
| derived platforms work.
|
| In any of these cases there may be one or more daemons
| behind the scenes handling the "raw" input--possibly even
| in cooperation with kernel-level pre-processing code, to
| ensure low latencey--but most event delivery to
| applications is associated with windows, with options to
| get lower-level access if needed.
|
| One of the things that helps many of the systems described
| above with latency is kernel participation, whether by
| pushing much of the preprocessing of events down to the
| drivers so there's little for userspace to do, or by
| implementing kernel-level zero-copy IPC (e.g. use of Mach
| messages by NeXT and Apple).
|
| If human interface IPC happens entirely in userspace and
| requires multiple context switches to get an event from
| device to a display change, you'll wind up with hitches and
| delays unless there's some sort of scheduler hinting that
| ensures each stage in the pipeline runs immediately after
| the last.
|
| This is, of course, why there was a lot of desire by
| Wayland advocates for kernel dbus support, but they went at
| the problem backwards: "Let's take DBus, and make it fast
| by putting it in-kernel," *without* first trying to make it
| as fast as possible without kernel support, *and* without
| trying to figure out the minimal feature set for kernel-
| level IPC that would be needed to support it (which may not
| look like DBus).
| BearOso wrote:
| This boils down to software cursor vs hardware cursor.
| mort96 wrote:
| I'm pretty sure this is incorrect? I half-remember having
| cursor rendering bugs on GNOME Wayland with NVidia ages ago
| which I had to disable something h hardware cursor related to
| fix. But I don't know if that's what you're talking about or
| not. Could you link to a source which says that Mutter doesn't
| make use of hardware cursor?
|
| (Hi, author here by the way! ... Don't worry, that disabling
| hardware cursors thing was at least one OS re-install ago)
| mariusor wrote:
| I wonder if the latency is due to the compositor receiving a
| damage event for the area of the cursor, thus being a frame
| late to render. But probably that wouldn't be an issue with
| hardware cursors.
| BearOso wrote:
| Yes, it should use hardware cursor by default on most
| hardware. But I don't think that RPi's VideoCore (in the
| linked article) supports hardware cursor or multiple planes.
| The difference between X11 and Wayland might then be that the
| cursor isn't vsynced as part of the composite process on X11,
| where it is on Wayland.
|
| Mutter definitely throttles cursor updates on Wayland, too,
| which will contribute slightly to latency even with a
| hardware cursor. In general, with Wayland, the compositor is
| responsible for cursor updates, and I'm not sure which other
| ones throttle. But that would be where the difference comes
| from when using hardware cursors.
| dividuum wrote:
| Pis VideoCore has like 48 planes split up between writeback
| and HDMI output CRTCs. There's one explicit Cursor plane
| per CRTC.
| BearOso wrote:
| Thanks, I didn't know this.
|
| I think the difference mort96 is seeing is the cursor
| update throttling. If it updates at the same rate of the
| refresh rate then it's a crapshoot where in that interval
| it hits relative to vsync, with a worst case additional
| latency of the frame rate. X11 updates the cursor
| whenever it moves, so on scanout it's always where you
| expect it to be, even if the motion was almost
| immediately before vsync.
|
| I should mention that in the past there's been
| problematic interactions on amdgpu with atomic updates of
| the cursor and display planes. This resulted in either
| one being starved from changing, causing stuttering in
| one or the other depending how it was handled. IIRC,
| that's why the throttle is there. You could try
| MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 to see if they only
| added the throttle to the atomic code path.
| itvision wrote:
| This assumption is incorrect.
| BearOso wrote:
| Thanks, I think you're right.
| hacker_homie wrote:
| I think you mean, The display server cursor (we can draw
| directly to the frame buffer) vs The Compositor Cursor (this
| involves and extra copy)
|
| It's all software.
| kelseyfrog wrote:
| > I don't have the statistics expertise necessary to properly
| analyze whether this difference is statistically significant or
| not,
|
| The two sample t-test statistic is -4.74 with a p-value of
| 4.20e-05.
| pwr22 wrote:
| and that means?
| kelseyfrog wrote:
| Depends on your alpha ;) . But it's significant.
| viraptor wrote:
| That _really_ does not answer the question.
| jampekka wrote:
| That there's a probability of 4.20e-05 that the observed
| difference of that large would happen by chance due to
| observation noise if there would be no real difference (given
| your assumptions about the data generating process holds).
| guerrilla wrote:
| I knew it! And when it does stall it takes way longer than X11.
| whatever1 wrote:
| Can't we port whatever android uses? Clearly the community cannot
| execute GUI related things at the level that a focused company
| can.
|
| Possibly because the best contributors don't care about GUI
| anyway.
| itvision wrote:
| Surface Flinger currently doesn't support well or at all multi-
| monitor configurations which are essential for the PC user.
|
| Otherwise, it's actually far more advanced than Wayland, and it
| had essential modern features implemented years ago, including
| HDR, VRR, and others.
|
| Why hasn't it been ported to Linux? Probably NiH, probably it's
| Google's child.
| dTal wrote:
| Ported to Linux? It runs on Linux. What exactly would need
| porting?
|
| What would be required to make surfaceflinger a practical
| Linux desktop compositor is merely some translation layer,
| equivalent to XWayland, that supports hardware acceleration.
| Such things have been written, but not open source and they
| never got traction.
|
| The idea has been toyed with for over a decade:
| https://news.ycombinator.com/item?id=5317638
| tuna74 wrote:
| Just do it!
| ChuckMcM wrote:
| 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 grade) I was all about the
| 'let's design an experiment' :-).
|
| Let me state up front that I have no idea why Wayland would have
| this additional latency. That said, having been active in the
| computer community at the 'birth' of X11 (yes I'm that old) I can
| tell you that there was, especially early on, a constant whine
| about screen latency. Whether it was cursor response or xterm
| scrolling. When "workstations" became a thing, they sometimes had
| explicit display hardware for just the mouse because that would
| cut out the latency of rendering the mouse in the frame. (not to
| mention the infamous XOR patent[1])
|
| As a result of all this whinging, the code paths that were
| between keyboard/mouse input and their effect on the screen, were
| _constantly_ being evaluated for ways to "speed them up and
| reduce latency." 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.
|
| [1] https://patents.google.com/patent/US4197590
| dralley wrote:
| 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.
| AtlasBarfed wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| vincent-manis wrote:
| >If the gnome composting ready for primetime, then
| Wayland isn't ready for primetime.
|
| I use Sway, which uses a different compos[i]tor than
| Gnome. I would like to see similar results for wlroots,
| Sway's compositor, though I'm not actually interested
| enough to do the experiment (I guess that would be
| comparing Sway with i3). Cursor lag in Sway is not enough
| to bother me. I have on occasion used Gnome on the same
| machine(s), and never been bothered by lag.
|
| As others have pointed out, Wayland is a protocol, not a
| compositor.
| tuna74 wrote:
| I have run Wayland since it was available for testing on
| Fedora Workstation and I have had zero problems inputting
| Japanese and Chinese.
|
| With regards to accessibility, what problems have you had
| exactly?
| prmoustache wrote:
| > the rush to use wayland and nearly every distro making
| it as default,
|
| Which rush? It has been done by only a small fraction of
| distros like Fedora, after years of development of the
| first wayland compositors. Fedora main purpose has always
| been to implement bleeding edge tech stuff early so that
| bugs get found and fixed before people using more stable
| distros have to suffer from it.
|
| Nobody has been forced in any regression and x11 has
| continued to be available until now and there is no sign
| that the most conservative distros will drop x11 support
| anytime soon.
| bawolff wrote:
| > Wayland is a protocol. The problems people complain about
| are generally implementation details specific to GNOME or
| KDE or (in general) one particular implementation.
|
| I feel like at some point this is a cop-out. Wayland is a
| protocol but its also a "system" involving many components.
| If the product as a whole doesn't work well then its still
| a failure regardless of which component's fault it is.
|
| Its a little like responding to someone saying we haven't
| reached the year of linux on the desktop by saying: well
| actually linux is just the kernel and its been ready for
| the desktop for ages. Technically true but also missing the
| point.
| washadjeffmad wrote:
| Wayland. Solving yesterday's problems, tomorrow.
| sweeter wrote:
| What components? Wayland is literally an XML protocol
| that turns an XML file into a method of communication.
| libwayland-server and libwayland-client only handle
| communication and the internal event loop. Its completely
| up to the developer to write the implementations of these
| functions and register them in the server.
|
| Then a client is going to query the server and ask
| request to do stuff via a unix socket. In fact, you don't
| even need libwayland, you can raw dog it over sockets
| manually. The idea is that there are standard protocols
| that can be queried and used,and you can implement this
| in any environment you want to. You could write the
| "frontend" in html and JS and run a wayland compositor on
| the web (which has been done [1]), you could do it with
| text or anything really, most people use some graphics
| stack.
|
| [1] https://github.com/udevbe/greenfield
| ahartmetz wrote:
| Nit: Wayland isn't an XML protocol. The "calls" and their
| arguments are described in XML, but the data is
| transmitted in a fairly simple binary encoding.
| o11c wrote:
| "Wayland is a protocol" is exactly the problem. Protocols
| suck; they just mean multiplying the possibility of bugs. A
| standard _implementation_ is far more valuable any day.
|
| With X11, it was simple: everybody used Xfree86 (or
| eventually the Xorg fork, but forks are not
| reimplementations) and libX11 (later libxcb was shimmed
| underneath with careful planning). The WM was bespoke, but
| it was small, nonintrusive, and out of the critical path,
| so bugs in it were neither numerous nor disastrous.
|
| But today, with Wayland, there is no plan. And there is no
| limit to the bugs, which must get patched time and time
| again every time they are implemented.
| dralley wrote:
| X had garbage handling of multiple monitors and
| especially multiple monitors with different DPIs, and
| there was "no plan" to deal with that either. Nobody
| wanted to work on the X codebase anymore. The
| architecture bore no resemblance to the way any other
| part of the desktop stack (or hardware) works.
| AshamedCaptain wrote:
| Most of the garbage aspect is because toolkits refuse to
| support multiple monitors on DPI with X11 with the
| argument that "Wayland is just around the corner", for
| decades now.
|
| For example Qt does per-monitor DPI just fine on X11;
| it's just that the way to specify/override the DPI values
| just sucks (an environment variable).
|
| This stupid decision is going to chase us until the end
| of times since Xwayland will have no standardized way to
| tell its clients about per-display DPI.
| sweeter wrote:
| Software has bugs and water is wet. Wait til you hear
| about HTTP, TCP, UDP, IP torrents, etc... and "simple" is
| not really a term I would designate to X11. I mean, its
| fine, but even just the ecosystem surrounding X is
| convoluted, outdated and absurd. Things like xinit,
| startx, .Xauthority, xresources, xhost etc... are all a
| mess.
| n144q wrote:
| > Wayland simply came at a time to further the delay of the
| Linux desktop
|
| I can't tell if you are serious or not.
| paulddraper wrote:
| Serious
| Cthulhu_ wrote:
| > How old is Wayland?
|
| About 16 years old, for comparison, X is 40.
| yencabulator wrote:
| You're arguing against Wayland, but for a more secure Linux
| desktop? I recommend you spend more time getting to know the
| X11 protocol then, because it has plenty of design decisions
| that simply cannot be secured. The same people who used to
| develop XFree86 designed Wayland to fix things that could not
| be fixed in the scope of X11.
| wmanley wrote:
| > the X11 protocol [...] has plenty of design decisions
| that simply cannot be secured.
|
| I've been hearing this for over a decade now. I don't get
| it. Just because xorg currently makes different clients
| aware of each other and broadcasts keypresses and mouse
| movements to all clients and allows screen capturing
| doesn't mean it has to. You could essentially give every
| application the impression that they are the only thing
| running.
|
| It might seem difficult to implement, but compare it to the
| effort that has gone into wayland across the whole
| ecosystem. Maybe that was the point - motivating people to
| work on X was too difficult, and the wayland approach
| manages to diffuse the work out to more people.
|
| I was really bullish on Wayland 10 years ago. Not so much
| any more. In retrospect it seems like a failure in
| technical leadership.
| prmoustache wrote:
| >but this is a forced change for the worse for so long
|
| Can you explain who is forced to do what in that context?
| arghwhat wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gf000 wrote:
| According to Asahi Lina, X does async ioctl that can
| update the cursor even during the scanout of the current
| frame, while Wayland does atomic, synced updates on
| everything, cursor involved, which has the benefit of no
| tearing and the cursor's state is always in sync with the
| content, but it does add an average of 1 more frame
| latency (either updates just in time for the next frame),
| or it _will_ go to the next frame.
| p_l wrote:
| Hardware cursor is still a thing to this day on pretty much all
| platforms.
| giantrobot wrote:
| > 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/
| ChuckMcM wrote:
| 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.
| gf000 wrote:
| Asahi Lina's comment on the topic:
| https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input...
| sylware wrote:
| Only one wayland compositor and then it is all wayland
| compositors???
| t3rra wrote:
| Answer: DLSS 4
| itvision wrote:
| Answer to what?
|
| DLSS was designed to solve performance issues, not architecture
| problems and poor design.
|
| And you absolutely wouldn't want your fonts or UI to be
| upscaled by it. You will hate every second of your experience.
| t3rra wrote:
| It was a joke. Why are you so serious? Did you have a bad
| day?
| soganess wrote:
| My response assumes that you are talking about the "frame
| warping" feature of Reflex 2 (saying DLSS 4 was misquoting
| Nvidia's PR jumble) not simply frame-gen/MFG or upscaling. MFG,
| while producing even more interpolated frames, does not improve
| latency and will probably make it worse. I suppose an argument
| could be made for upscaling in a roundabout may (lower internal
| resolution = more frames = faster response time) but that would
| be more true for DLSS 3 as it has a lower GPU overhead than the
| transformer-based DLSS 4
|
| Anyways, even if it were the case that graphic stack produces a
| response to the input by warping the frame during interpolation
| / before rendering, the input that triggers said response would
| (certius paribus) still go through libinput (and most likely
| the Wayland compositor) so timing would remain the same. For
| any features to improve on response time, it would likely have
| to circumvent one (if not both) libraries.
| t3rra wrote:
| I know I know. I just made a joke. And I know you cannot get
| it. Seriously, you two guys are so serious. What is the
| problem with you?
| ray023 wrote:
| I also have no ideas how it works, but my guess would be that is
| actually translates exactly like that into games. Why would the
| mouse on the desktop have a latency that games do not have. Linux
| does not have a real fullscreen mode like Windows has (that I do
| not use anymore anyway for faster alt-tabbing). So my guess is,
| the cursor or mouse input gets into games very much the same way
| as it gets in the desktop.
| gsich wrote:
| Hardware cursor might be used in games. You notice the
| difference on Windows if a GPU does not support it, even on the
| desktop.
| zamalek wrote:
| Wayland has support for games completely taking over the GPU;
| notoriously critical for VR support. This is basically the same
| as Windows exclusive full screen.
|
| Wine/proton would need to support it, XWayland would need to
| support it (Wine/Proton are one major step away from native
| Wayland support: Vulkan), and finally the compositor would need
| to support it. Gnome is about the worst compositor that you
| could be testing any of this stuff on, they are comically
| hostile towards ideas not their own. The chances of this ever
| working on Gnome are near zero. KDE is pretty good for support,
| Hyprland seems to be trying to support every under the sun.
| debugnik wrote:
| > notoriously critical for VR support. This is basically the
| same as Windows exclusive full screen.
|
| D3D12 dropped support for exclusive fullscreen, and I don't
| think headsets even go through DXGI but their own swap chain
| APIs. Why do VR games on Linux need the equivalent from the
| Wayland compositor?
| mixmastamyk wrote:
| Looked up the mouse to see how fast it updates and read that it
| is wireless. Kind of disappointing and might explain some of the
| variance. Although if X11 is consistently faster the test should
| still have some validity.
|
| Would like to see a test with gnome and the wireless mouse
| removed from the equation.
| IshKebab wrote:
| Yeah testing this with a wireless mouse is dumb. The proper way
| is to use an Arduino or similar as a USB mouse, and connect a
| photodiode to it too.
|
| USB mice update at 1 kHz.
| viraptor wrote:
| It depends on the model. Wireless mice don't have to be
| slower than wired. But even then, for this test it's
| irrelevant. It's the same mouse in both scenarios, and we
| only care about the difference. Even if a wired mouse
| stripped X ms on both sides, the result would be the same.
| IshKebab wrote:
| It does matter because the latency of a wireless mouse
| isn't necessarily consistent, so it adds noise into an
| already very high noise set-up.
| viraptor wrote:
| That's only a problem if the noise of wireless is higher
| than the signal (measured delay difference). And we can
| see from the data it isn't. Unless you're claiming it can
| be consistently different by ~5ms between those two
| tests... but that's very unlikely. Like, "you should
| demonstrate it" unlikely.
| gsich wrote:
| You need a setup like this guy:
| https://www.youtube.com/watch?v=nbu3ySrRNVc
| SaintSeiya wrote:
| Why this does not surprise me? every attempt to rewrite a working
| solution to make it more "modern, easy to maintain and future
| proof" rarely do so. It always end up slower, with more latency
| and lifted by faster hardware, not by faster software. Every 20
| years a new generation comes weaker, pampered with the
| abtsractions of the previous generations who did the grunt work
| for them. After 3 generations of software developers all we have
| is library/framework callers and nobody really knows about
| performance and optimization.
| kombine wrote:
| This is not my experience. When I upgraded several of my
| computers to KDE 6 switching to Wayland, overall responsiveness
| and snappiness of the system increased very visibly. There are
| still features that Wayland lacks compared to X11, but I am
| willing to compromise in favor of its other benefits.
| mtlmtlmtlmtl wrote:
| On the other hand, I just did a fresh install of Artix Linux.
| Installed KDE just to have something functional while I get
| my tiling setup working. Boot into Plasma(Wayland) and it
| utterly shits itself, turning my main monitor on and off
| repeatedly until it finally crashes. So I pick Plasma(X11)
| instead and that just works.
|
| In fact, in almost 2 decades of using Linux every day, I
| can't remember X doing anything similar. It's always just
| worked.
| dvdkon wrote:
| Same here, switching from i3 to sway resulted in a noticeably
| more responsive experience on my aging hardware. Of course,
| this is just an anecdote, and I could probably get the same
| results on X with some fiddling, but I do think the value of
| simpler and more modern systems is demonstrated here.
| prmoustache wrote:
| Old computers had less latency, but otoh on many OSes a single
| app crashing meant the whole OS was irresponsive and you had to
| reboot the whole system.
| Avamander wrote:
| Less latency matters little if it's just to wait behind some
| other operation like disk IO or network.
| haunter wrote:
| Does the Nvidia FrameView app works under Linux (or more like
| under X11 and Wayland)? You can measure general system latency
| with that https://www.nvidia.com/en-
| us/geforce/technologies/frameview/
| PeakKS wrote:
| This is pretty bad methodology for someone to call it "Hard
| numbers"
| sapiogram wrote:
| If you're unhappy about their methodology, you're welcome to
| write productively about your specific gripes.
| jay_kyburz wrote:
| Yes, I was expecting some software that listens directly to the
| mouse input, and watches a pixel on the screen. Messing around
| with cameras and counting frames introduces a whole bunch of
| other variables like the quality of the monitor and mouse and
| phone used for recording.
| ggreer wrote:
| The camera, mouse, and monitor all stayed the same for the
| tests, but there was a significant difference in latency. Out
| of the 16 times the experiment was run, only once did Wayland
| have lower latency. It would be an amazing coincidence if the
| monitor, mouse, and/or camera were the reason for this.
|
| Figuring out _why_ there 's increased latency is a job for
| software tooling, but I think this guy's experiment is one of
| the best ways to measure what users care about: The time it
| takes for an input (such as mouse movement) to result in a
| change (such as cursor movement).
|
| Note that this doesn't mean that the Wayland protocol itself
| is the reason for the higher latency. It may be Gnome's
| implementation (testing with a wlroots compositor might shed
| light on this). It may be differences in default
| configuration options. It may be that Wayland and X11 start
| up different services, and the Wayland helper processes
| increase load on the machine. But I seriously doubt the
| reason for the difference in latency was because the same
| hardware was used throughout the experiment.
| tuna74 wrote:
| How would you "watch a pixel on the screen" in pure software.
| You need a camera and an input device in the loop.
| jay_kyburz wrote:
| Is it not possible to simply query the frame buffer right
| before its sent down the HDMI cable. What color is pixel
| 0,0?
| tuna74 wrote:
| Maybe you could do that by hacking the driver in a Linux
| system? I don't know actually.
| viraptor wrote:
| The mouse and monitor don't matter here. Unless their delay
| completely dominates the timing (it doesn't here) they can be
| ignored because the setup is constant been the tests. We're
| interested in the difference, not the absolute numbers.
| lolc wrote:
| The chosen protocol works fine to answer the question.
| Overall latency is what counts.
| cakealert wrote:
| Would have been nice to see if the issue is present on wlroots
| compositors, GNOME rolled their own.
| delusional wrote:
| I did some work to create a simple device to measure this some
| yeas ago. The intention was for developers to use it to regularly
| benchmark their software. It costs like 20 bucks and takes 10
| minutes to build.
|
| I might get to run some benchmarks myself next week.
|
| https://jnsn.dev/posts/frametime/ with a follow-up in
| https://jnsn.dev/posts/fastisslow/ or if you just want to see the
| code without my jabbering:
| https://github.com/DelusionalLogic/Frametime
| bitwize wrote:
| Composited desktops have their drawbacks. With a display system
| like X11 or old-school GDI-based Windows, draws to the display
| are next to immediate, whereas with composited desktops,
| everybody has to draw to a back buffer, then the back buffers
| have to be composited together on the final display, adding at
| least one frame of latency. Mouse cursors have been a hardware
| sprite since the 90s, but Wayland compositors may favor using the
| GPU to draw a soft cursor.
|
| It'd be interesting to see a compositor that can speak Wayland,
| yet performs immediate, region-clipped draws of all windows like
| X11 conventionally does.
| goodburb wrote:
| It's much worse with Nvidia 30+ series on Wayland, feels worse
| than a Bluetooth mouse, using Nouveau eliminates lag for the most
| part.
| Cthulhu_ wrote:
| TIL Wayland is 16 years old already; in a few years (I can't
| math) it'll be as old as X was when Wayland came out, but it
| seems it's still considered mediocre or not as good as X was.
| tmtvl wrote:
| If X is 40 and Wayland is 16,that means a difference of 24
| years. Hence Wayland compositors have 8 years to work out the
| kinks. I am currently using Wayland via Plasma 6 and it works
| well enough but I don't have special needs, so I don't know how
| well... say... screen readers work.
| DonHopkins wrote:
| That means in two more years it will be legal for X11 and
| Wayland to have a baby!
| craftkiller wrote:
| > 16 years old [...] in a few years [...] it'll be as old as X
| was when Wayland came out
|
| Lol no. X is from 1984: https://www.talisman.org/x-debut.shtml
|
| That means Wayland is only 66% the age of X when Wayland came
| out, or you'd need 50% more of Wayland's life before its as old
| as X was.
| tannhaeuser wrote:
| Another way to look at these figures is that in a few years a
| Wayland successor is due, born out of the same motivation as
| Wayland ie. lack of people with a desire to maintain legacy
| software. My expectation is that browser frontend stacks will
| eat the desktop completely at that point; it's not like there
| weren't many new desktop apps on Linux anyway.
| dist-epoch wrote:
| Wayland came out at the same time as the Windows compositor in
| Vista. Let's be generous and consider the next Windows version,
| 7, as having a "good/stable" compositor. So Wayland is 13 years
| behind Windows.
| jzb wrote:
| Initial release of X was June 1984, and Wayland was first
| released in 2008 -- so it won't be until 2032 that Wayland is
| the same age. When people complain about Wayland being mediocre
| or "as good as X was" what they often mean is "Wayland doesn't
| support $very_specific_feature" or "my video card vendor's
| proprietary drivers aren't well-tested with Wayland and it
| makes me sad".
|
| Approximately 99.999% of those complaints are uttered by people
| who 1) are not doing the work, 2) are not interested or capable
| of doing the work, and 3) do not understand or refuse to
| acknowledge that the Wayland and X developers are _mostly the
| same folks_ and they _do not want to work on X11 anymore_.
|
| I don't really have a stake in this argument, except I'm bone-
| tired of seeing people whine about Wayland when they're using
| software somebody else gave them for free. There are enough
| Wayland whiners that, by now, they could've banded together and
| started maintaining / improving X and (if their complaints and
| theories were correct) left Wayland behind.
|
| Strangely -- even though X is open source and eminently
| forkable (we know this, because XFree86 -> X.org) it gathers
| dust and none of its proponents are doing anything towards its
| upkeep.
|
| When someone shows up with "Wayland isn't as good as X, so here
| is my modernized fork of X anyone can use" -- I'll be quite
| interested.
| soganess wrote:
| Great work, I hope the gnome/wayland devs appreciate it.
|
| I wonder if there is an issue with high frame rate support in
| Gnome (or possibly wayland?). It seems like they are actively
| still working on it:
|
| https://9to5linux.com/gnome-47-3-improves-frame-rate-for-mon...
| PeakKS wrote:
| No, that article is about copying frames between gpus
| soganess wrote:
| Agreed. That was just the latest related article I saw. I was
| bring it up to support my claim of "high framerate support is
| still new/developing in Gnome"... embarrassingly my old man
| brain compressed time... it's been 6 years[1], oh well.
|
| [1]:https://www.phoronix.com/news/GNOME-Still-Dropping-
| Latency
| light_hue_1 wrote:
| Wayland has just been a disaster for the open source desktop.
| It's absorbed all of the effort into something horrifically
| subpar while breaking compatibility with the past.
|
| Accessibly is far worse to the point of embarrassment. Latency is
| worse. Compatibility is gone. Everyone in the ecosystem needs to
| do more work to end up with fewer features for end users.
|
| This is the opposite of systemd in every way. Systemd upset a lot
| of people because it was entirely user focused and didn't care
| about the beauty of the architecture. Wayland is only obsessed
| with how nice their apis are, not what the end user experience
| is.
|
| Let's end this disaster. It's been 16 years. It's almost old
| enough to vote. When will we accept it has failed?
| prmoustache wrote:
| x11 failed in other areas, and earlier.
|
| So what is your proposal, starting again from a blank sheet?
|
| I don't think it will help.
| Gormo wrote:
| > x11 failed in other areas, and earlier.
|
| Still works great for me!
| prmoustache wrote:
| as do wayland for the majority of its users.
|
| Fine, we are all happy then.
| tuna74 wrote:
| "Let's end this disaster. It's been 16 years. It's almost old
| enough to vote. When will we accept it has failed?"
|
| Use what you think is better then.
| hacker_homie wrote:
| I mean X11 was a pile of hacks, it became an unmaintainable
| pile of hacks. I think reduced scope was a good call, writing a
| display server is a hard problem. A lot projects started and
| failed to replace X11.
|
| If you feel this way I recommend watching this talk by Daniel
| Stone from linux.conf.au 2013, The Real Story Behind Wayland
| and X https://www.youtube.com/watch?v=RIctzAQOe44
| sprash wrote:
| It should be easy to create something better than X11. And if not
| pour more resources into X11 developement. Wayland on the other
| hand is a complete failure on all fronts. It should be abandoned
| ASAP.
| PeakKS wrote:
| Well it's already better than X11, so task accomplished.
| sprash wrote:
| What exactly is better? I can't even think of a single thing.
|
| It has worse performance on almost all metrics. Heavy
| fragmentation. Very limited and incomplete API measured in
| functionality but still extremely complicated to work with as
| developer. Extremely slow development. The only thing that it
| has over X11 is better funding (for whatever reason).
| mixedCase wrote:
| Are we really pretending multi-monitor on X is not an
| absolutely shit show? Try mixed DPI and VRR in one of the
| monitors and see how you get that working well.
| sprash wrote:
| The VRR issue can be solved with a simple patch that
| never got merged into mainline (no idea why). Hence it's
| not inherently a X11 problem and honestly also a rather
| niche problem compared to the humongous deficits Wayland
| brings.
|
| Mixed DPI works perfectly fine on X11 if the toolkit
| supports it. The xrandr protocol provides all the
| necessary dpi information. GNOME simply chose not to
| support it on X11.
| Gormo wrote:
| I have _zero_ issues with multiple monitors, with mixed
| DPIs and refresh rates, and different scaling factors on
| each display, using XFCE under Xorg.
| perihelions wrote:
| For those of you who are application developers on Linux/Wayland,
| do you use any other methods for benchmarking true latencies
| between input events and screen? Less heroic than the high-speed
| camera method. I'm embarrassed I've still never figured this out
| properly.
| freehorse wrote:
| A photocell is I think the standard (or at least "the standard"
| in psychophysics applications I have also used). You need,
| though, to make sure your event causes a change that a simple
| photocell would detect (eg you have a corner of your screen or
| application window having a small square that turns from black
| to white and vice versa). You can connect that to an arduino or
| whatever you can use to get both signals in some low latency
| way (one from user interaction or whatever causes the event,
| and one from the event itself with that light intensity
| change). There are also photocells with a higher granularity
| for luminosity changes than just light/dark, so maybe you do
| not need to have the black/white square thing, just something
| that causes enough luminosity change to be detected. This
| should, in principle, give you very accurate timings if you can
| also get the event initiator somehow with low latency (or you
| can do stuff like simulate an event periodically and look for
| skipped frames/variance in the screen presentation rather than
| latency).
| sweeter wrote:
| Its very interesting, but I would love to see other Wayland
| implementations other than GNOME's. Its kind of hard to tell if
| its the GNOME specific implementation or if this is going to be a
| trend across KDE X vs KDE wayland and specific window managers
| like sway -> i3 and hyprland etc... But still a really cool blog
| post.
| shmerl wrote:
| _> GNOME Wayland session_
|
| I wouldn't use that. Try KDE if you want a decent gaming
| experience. Gnome was very slow in even implementing something
| like adaptive sync, so they hardly are prioritizing latency
| issues for the end user.
|
| I.e. Gnome's problems [?] Wayland problems in the broader sense.
| Conflating the two is wrong.
| sprash wrote:
| Wayland lacks a strong reference implementation. The resulting
| fragmentation in the ecosystem turns the most popular
| compositors into de-facto standards every application developer
| will have to use as a reference.
|
| This means Gnome's problems = Wayland problems.
|
| Furthermore, the latency issues with Wayland are inherent.
| Compositors will always have worse latency than writing
| directly to the front buffer.
| shmerl wrote:
| The kind of issues referenced in the article are not related
| to compositors being compositors though, but to bad
| implementations.
|
| Gnome is big, but it's not the most popular DE out there, so
| it can't be treated even as a de-facto standard in the
| Wayland world. Some things might be treated that way, but
| they are lower level (let's say Pipewire, libinput etc.).
|
| And regardless, it can't be used an example that blames
| Wayland for Gnome's issues, unless literally every single
| compositor has this problem and the real reason is Wayland's
| inherent limitations. There are such limitations in general
| indeed due to Wayland still evolving, but this isn't one of
| them.
| mattbee wrote:
| I've used https://isitsnappy.com/ on the iPhone to do these kinds
| of measurements pretty quickly, to substantiate why I sucked at
| Steam Deck rhythm games when connected to a TV.
|
| (I do not suck, my setup had 100ms lag)
| abhinavk wrote:
| Great app. I hope next iPhones have improved slow-motion camera
| modes. 1000fps will be a long shot but maybe 480/500fps.
| davet91 wrote:
| What was the issue with your setup? TV not in game mode?
| mattbee wrote:
| Never got to the bottom of it. TV was set to game mode, I
| tried various scaler settings on the deck itself, couldn't
| get it below about 90-100ms. I've tried on two TVs.
|
| You can learn to play Space Channel 5 by tapping 100ms ahead
| of the beat. But I worried that if I succeeded too much, I'd
| end up doing everything that way: jumping red lights, taking
| espresso shots while they were still being poured etc.
| rezmason wrote:
| This reminds me of the early work of the structuralists in
| psychology. Measuring the time it takes for a person (or in this
| case Wayland) to react to a sensation.
| colonial wrote:
| Funny, I didn't even know this was a debate. I didn't even notice
| when Fedora switched from X to Wayland by default - maybe because
| I'm still a 60hz plebian?
|
| I _have_ experienced issues with my mouse input locking up
| /jumping - especially noticeable when I'm playing a shooter - but
| I'm pretty sure that's just my poor ancient mouse giving out.
___________________________________________________________________
(page generated 2025-01-26 23:00 UTC)