I know most of you are either underaged zoomers or mentally challenged manchildren, but... here is why Xorg is a complete piece of trash compared to Wayland.
>b-but muh vsync
Enjoy your cope.
>better power efficiency = better and more stable overclocks = faster PC
Dominic Sullivan
Other urls found in this thread:
freedesktop.org
twitter.com
Grayson Cruz
>still doesn't have a good window manager
Thanks but I'll stick with X
Luis Hall
>my_opinion.txt
>Thanks, but I'll stick eating shit
okay buddy
Dominic Cruz
>t.
Ayden Edwards
>better power efficiency
Sauce?
Shouldn't it be the opposite since it forces you to use a compositor?
Christian Brown
Even comparison "benchmark" uses one because Wayland forces it, so Xorg has to be crippled to make it "fair".
Joshua Mitchell
~0.1W difference won't make or break an overclock.
Nicholas Thomas
I'm really rooting for Wayland, but atm chromium tab groups don't work properly on it, screensharing only works with pipewire (which I'm fine with, I use Fedora, but many people don't) and Nvidia drivers for my GPU don't work with it (I'm stuck on 470xx).
Henry Howard
>atm chromium tab groups don't work properly on it
I'm using tab groups just fine on it. What doesn't work?
Jace Wood
In my case whenever I try to move one of the tabs either out of a group or into a group, it switches to a new window and I can't readd it to the old window. I can right click and select which window to move a tab to but not by dragging. I tried switching to xorg and the problem didn't occur so I assumed it was a wayland issue. I guess I'll have to try another chromium based browser to be sure, ehich one are you using?
Ian Thompson
Compositing is only inefficient on X.
Wayland is still more efficient.
Grayson Peterson
ungoogled-chromium, and moving tabs around as you describe works fine
Brandon Wood
>Can't even run XEyes because muh security
No thanks.
Dominic Diaz
I'll try it, but I'm guessing my problem was somewhere else anyway, since I dubt implementations for tab groups differ.
Cameron Young
Funnily enough xeyes is more useful on Wayland than on X
Xavier Baker
Wayland basically requires the 3D engine to be fired up nonstop, while Xorg doesn't. Even when literally nothing but the clock in the corner is changing the chip can't power down to save power.
Meanwhile on Xorg compositors can use XRender, which will happily do it's job using just a simple, energy efficient blitter.
Matthew Reed
>the chip can't power down to save power
Yes it can (this applies for any OS). What sort of shit GPU do you have?
>which will happily do it's job using just a simple, energy efficient blitter
freedesktop.org
Alexander Sanchez
Wayland is so efficient that some GPUs go into a low power state during normal operation and sometimes struggle to go back to a normal power mode in time when a load spike comes in. Wayland is literally more efficient than what hardware manufacturers thought was possible.
Leo Turner
>better power efficiency
Until you enable fractional scaling
Jeremiah Lee
i don't know or care if i use wayland or not. i just checked the box for xfce when installing linux (debian) and called it a day since it works fine enough for me and "if it ain't broke don't fix it"
Carter Lopez
...something Xorg doesn't have in the first place
Lincoln Miller
You can set exact dpi values in xorg genius.
Leo Long
Same as Wayland then, but that's not scaling.
Nathaniel Murphy
I have work to do kid, don't have time to do free QA for Red Hat, I'll switch to Wayland when it's stable in 2030
Colton Davis
>Yes it can (this applies for any OS). What sort of shit GPU do you have?
WTF are you talking about?
>freedesktop.org
What about it? It's a fallback in case the devs are to lazy to write a proper XRender implementation or in case the graphics hardware has no dedicated 2D block.
No, that was because of forced vsync and assumptions in the graphics drivers about how GPU load translates into clock rates. Also that was only a GNOME problem.
Benjamin Davis
>Same as Wayland then
Wrong. The api only allows for integer scaling. Fractional scaling is implemented in compositors as a massive, inefficient hack. Also, Xft.dpi absolutely is fucking scaling. Most applications use it.
Carter Green
Also scaling is a toolkit problem, not a display server problem.
Problem is GTK is a piece of shit, so you have to do it sometimes in the display server anyway (mixed DPI setups). But Wayland doesn't fix any of this, it's the same ugly bilinear raster image scaling either way. On Xorg it's just applied to the whole screen at once instead of on a per-window basis. End result is the same, though. Only Qt gets this right.
Brandon Green
All waytards have to do is make scale a double. That would fix it, but no we can't have that.
Evan Young
>WTF are you talking about?
All modern GPUs have comprehensive clock gating, so they can power down unused parts during idle. The 3D engine is only active for a fraction of a millisecond when rendering the desktop.
>What about it? It's a fallback in case the devs are to lazy to write a proper XRender implementation or in case the graphics hardware has no dedicated 2D block.
It's the XRender implementation used on everything except xf86-video-intel, which is deprecated. NVIDIA doesn't count because you shouldn't use proprietary drivers on Linux. Rendering with GL is the most efficient option because that's literally what all modern GPUs were designed to do.