Originally posted by tildearrow
View Post
Announcement
Collapse
No announcement yet.
KWin-LowLatency: An Effort To Yield Less Stutter & Lower Latency With The KDE Desktop
Collapse
X
-
I've tested it and it is pretty big difference, the biggest show is the reduced input lag as we do not feel more like things are trying to catch the mouse, but there is still stutters in some places.
I remember there was a plan of running Kwin in real-time when it comes do Wayland, not sure how it is going as I have an NVIDIA GPU. Anyway lets see, if NVIDIA does nothing to get its GPU going well apart from games in Linux, I will move to AMD next time... Game is less than 10% of my computer time.
- 1 like
Comment
-
Originally posted by RomuloP View PostI've tested it and it is pretty big difference, the biggest show is the reduced input lag as we do not feel more like things are trying to catch the mouse, but there is still stutters in some places.
I remember there was a plan of running Kwin in real-time when it comes do Wayland, not sure how it is going as I have an NVIDIA GPU. Anyway lets see, if NVIDIA does nothing to get its GPU going well apart from games in Linux, I will move to AMD next time... Game is less than 10% of my computer time.
Comment
-
Originally posted by shmerl View PostAnd adaptive sync situation is even worse, due to Wayland protocol itself missing features:
https://gitlab.freedesktop.org/wayla...84#note_136147
You need to read above more carefully.
implement an API with which apps can ask for VRR
You missed this line. note also the "possibly Mesa" before this.
Wayland the protocol is designed to be client side rendering. Just like it started as client side decorations.
So the fact that in opengl and vulkan you can tag a surface as VRR the compositor can in fact query this. There is no need for the wayland protocol to transfer this information.
What you would want a wayland extention for is so application could request adaptive sync with min and max speeds off the compositor and the like. But these don't have to be done in wayland protocol these could be done in opengl/vulkan buffer metadata.
The features todo adaptive sync in Wayland is not missing. Features for friendliness could be classed as missing.
The adaptive sync issue on Wayland is simpler than X11 since the Wayland protocol made sure it did not include sync primitives and pushed sync primitives into opengl/vulkan/drivers.
Comment
-
Originally posted by tildearrow View Post
Adding a Vulkan back-end to the compositor will be an extremely tough task as I have zero knowledge of Vulkan.
I will eventually have a look at Wayland, however.
Comment
-
Originally posted by oiaohm View PostSo the fact that in opengl and vulkan you can tag a surface as VRR the compositor can in fact query this. There is no need for the wayland protocol to transfer this information.
Comment
-
Originally posted by shmerl View PostIt better should, otherwise compositors will use a mess of different methods of detecting it. Wayland situation is already rather messy as it is, with compositors barely managing doing things in a similar fashion. No need to make it worse.
Lets just do the stuff in the drivers that should be done in the drivers. VRR is a driver thing/graphics library thing(mesa/vulkan/opengl). No need to mess up wayland protocol with this stuff.
Pays to remember Wayland is client side render. X11 is designed as server side render so it does have to provide sync primitives and this lead to mesa and x11 disagreeing at times.
You have to remember opengl and vulkan has sync primitives already and extras to support VRR. So adding VRR to wayland protcol is basically duplicating the wheel and having the wheel studs per wheel. Opengl/vulkan is really were VRR work needs to be. Why such a critical fail because you can bet some applications will use opengl/vulkan request methods in time and other applications will use wayland if you provide both. Sometimes you are better off not supporting stuff because it does not make sense.
Yes VRR is bad enough with Opengl and Vulkan we don't need third wheels.
Comment
-
Originally posted by debianxfce View PostNo sense to run Xwayland when the X windowing system rules. Wayland and gnome3 will fade away in the future. More and more people realize how bad it is,see Linux news:
https://www.forbes.com/sites/jasonev...-surprise-you/
- 1 like
Comment
-
-
Originally posted by debianxfce View PostThat is your personal opinion, not a technical fact. A fact is that wayland is not ready and popular and never will be. Time has passed by of wayland in 10 years, you can use the Xfce desktop with a pentium III computer.
Sway currently is functional on weaker hardware than xfce can run on.
- 1 like
Comment
Comment