Originally posted by Alexmitter
View Post
Announcement
Collapse
No announcement yet.
Experimental Wayland Support For Wine Now Sees More Functionality Working
Collapse
X
-
Originally posted by Alexmitter View Post
You have fallen into the trap of thinking "improved performance == better FPS".
This is about things like not piping around the picture 3 times before it hits the framebuffer, proper vblank timing, improved CPU usage, faster frame presenting. Those are all things that suck on X11 and are unfixable.
Playing a fast pace rhythm game on Xorg? Forget it.
Want to use a low power device like the Pinephone or Pinebook Pro with Xorg? Forget it, it sucks, its unusable while wayland desktops run fine.
EDIT: It's funny because I have a fairly high end machine and Gnome and Plasma wayland sessions both become a laggy unusable mess under moderate CPU load.
EDIT: Although Gnome has some multithreading work coming that will help with it soon. Still though, how many years has it been to get this far?Last edited by duby229; 19 February 2021, 02:06 PM.
Comment
-
Originally posted by RahulSundaram View Post
I haven't seen anyone actually working on Wayland claiming it has better performance or even that it was a goal. Have you?
- Likes 2
Comment
-
Originally posted by Luke_Wolf View Postand that X11 concepts like unredirection weren't necessary on Wayland.
- Likes 1
Comment
-
Originally posted by Alexmitter View PostI already played around with the original commit state from the last announcement and it was already working very well, can't wait to see it being merged.
The people at collabora are just amazing.
Having a positive answer from Alexandre (viz. that a Wayland driver is
desirable) is one thing, and would be necessary for me to agree to
maintain the driver, but I'd also like to see the following before
accepting anything into wine-staging:
* The driver should be at least as feature-complete as the X11 driver.
Ideally, it should be *more* feature-complete. That includes not just
support at the protocol level, but actual implemented support across all
major window managers. There's no point accepting the driver into
wine-staging if it's not enabled by default, and I want to deal with as
few bug reports as I possibly can. This also helps prove that the driver
is not a bad idea.
* A promise from the developers to respond promptly to all bug reports
concerning window management (provided, I guess, that the same bug
reports don't occur with the X11 driver).
* A promise from the developers to deal with any difficult rebase work.
Rebasing is normally our responsibility as wine-staging maintainers, but
for large and difficult patch sets we do request that the author be on
hand to maintain their own work.
* A promise from the developers to try to upstream the driver after it
is introduced into wine-staging. I will *not* be upstreaming the driver
myself, and I do *not* intend to maintain it forever. Please do not
treat wine-staging as an end goal in itself—it is a testing ground and
nothing more.
Even with all that, I'm not thrilled about the driver. I recognize I may
not have a choice in the matter, and I recognize I'm not an X11
developer and thus lack significant context, but I don't like the way a
feature-incomplete protocol has been forcibly pushed on applications
with the apparent intent of quickly replacing and removing its predecessor.
ἔρρωσο,
Zebediah
Whilst I absolutely understand some of the concerns of maintaining such a driver, I always get the feeling most people at Codeweavers just don't like change or adapting the status quo much. The upstreaming of DXVK being refused (for mostly political reasons) as a prime example. I wonder if Collabora has a little more sway with Codeweavers.
Comment
Comment