wayland stops the whole program from working when it is not visible on the screen
this bugs with mpv, as mpv start to buffer so much memory that starts to hang the computer
this bugs with firefox, as any window that is not visible freezes everything else (including the visible windows)
this bugs with any fricking game because delta times becomes so fricking big that any movement will lead to out-of-bound situation
... when linux will stop being always in beta?
 CRIME Shirt $21.68 |
 Ape Out Shirt $21.68 |
CRIME Shirt $21.68 |
>wayland
Linux is a kernel. Wayland is userspace troonware.
and before anyone say anything
i tested on gnome, hyprland, dwl, all of them have this behavior and it is annoying, i simply can't play videos in background because of this
a moronic kernel i might add, bsd is more consistent
i'm only on linux because of drivers
wayland is a joke, i'm going to keep using xorg
It just stops rendering when there's nothing to render.
no, minimize the window or move to another workspace and it simply stops rendering
this breaks mpv
i recorded a video showing this problem with a simple glfw program that just counts frames, and i even had to keep obs visible if it is not visible it stops working and does not record anything.
From what i saw, this problem is indeed with the implementation of the protocol, as it does not send render events when it is not visible.
There's nothing to render if it's minimized.
mpv and all other programs for that matter uses frames as a way to consume stuff, for example: mpv uses frames as a way to consume the buffered data, games uses frames as a way to measure delta times, etc. if we don't use frames anymore, the whole point of the wayland is useless as everything will have to become unsynchronized again in the client-side just to solve this problem
and just to stress a little bit more: this does happens with hyprland and dwl as well. It is not just a gnome problem.
Is that really still an issue with mpv in current year? They rewrote everything to conform to what the wayland Black folk wanted.
>another basic functionality such as minimizing the fricking program is broken
Waylandsisters...
How new is your copy of mpv, does it have this fix?
https://github.com/mpv-player/mpv/commit/99d387bbc81e36f60da26d63b96736e2461bcd2e
when i'm seeing a video from youtube, for example, and minimize the mpv for a time, it holds the video frame and after i restore it back it just fast forwards every single frame to the current frame.
i didn't debug this but i think it never reaches the talloc_free line.
does setting damage_tracking to 0 help? i'm not going to try myself since i have no time to skim hyprland code to make sure there's nothing bad in it
Tried here and still do have problem.
Well, i will see this render event for myself.
all those applications don't support wayland properly then.
i doubt the firefox issue though since i have many minimized firefox windows.
>be wayland Black person
>observe that every other windowing system does thing X
>deduce that every existing application likely relies on X to work properly
>do the opposite of X
>blame and berate application authors when they don't work
while i understand why they'd want to do it, which is that ideally you would want to save resources and power by not rendering things which aren't visible, but i think for the sake of compatibility, this behaviour should not be the default, but rather something a program requests if it can handle it gracefully. tons of programs use rendered frames for timekeeping/pacing one way or another, which makes sense as in most cases graphics programs are most likely to be spending most of their time rendering, you should be pacing things based on the slowest component
That one angry Valve contractor is trying to get a protocol in to fix this. The patches have been stuck in code review hell for years, with even angrier Wayland people stalling them, suggesting worse workarounds and getting into huge pissing contests with the Valve guy. It's kind of a fun read.
great, another extension to the protocol
almost like X's "do whatever you want i don't care" approach just werks better
link?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18359
first line:
>This protocol provides the ability for clients to know when their surfaces
are suspended or restored.
hang, on, they don't even /know/ if they're being suspended? how the frick was this ever meant to work?
they stop receiving the frame callback and if they need to know they're suspended then they can implement a timeout
You're not supposed to know. The wayland guys saw that every application has logic in the main event loop and decided this is stupid. You should be running that on other threads. And the world simply must be rewritten to conform to the wayland view. You know who believed in backwards compatibility? Hitler.
HOW DO YOU EVEN MAKE A GAME WITHOUT PACING THE GAME WITH THE FRAMERATE?
THEY ARE moronic?
Well, to be fair, for games you want to cap the maximum delta anyway, because there are situations on all platforms where you can get fricked over by the window system not giving you callbacks (e.g. during resize on Windows).
i've seen enough speedruns to know this to be true, plenty of games where intentionally causing a big enough lag spike can lead to clipping
while i'm sure capping it would be fine (it would just mean gameplay slows down under the cap, but you can set it low enough that nobody would reasonably want to play the game under that rate anyway, like 10fps), that's something you'd have to change in the game itself, and that's not happening for existing/older games
every single program in existence does the logic in the main loop
sure, but what we're talking about is how games compensate for different fps by adjusting the speed of the gameplay, which allows for example to walk the same speed regardless of if the game is running at 30fps or 60fps, at 30fps you move twice as much per frame as 60fps, issues can pop up at very low fps, like how much would you move in one frame if the game lagged for half a second? doesn't sound like an issue, but this also affects physics, if you're walking towards a wall, and the game lags hard, maybe you'll just go right through the wall as on one frame you were on one side of it, and the next frame you were on the other size, because you moved a long way in one frame, it doesn't know what happened in between, those frames never existed
Wayland only exists to sabotage desktop linux now that its marketshare is making MS uncomfortable.
The Wayland case is so demoralising. I just switched to X and could count at least 6 bugs being instantly fixed.
Uhm based? If you are not looking, why should it do anything? That's like the programs are running behind your back.
>moronic android user
>issue that was solved in windows 95 still exists in 2024
It is worse, it was solved on linux too, but it returned because of wayland
Wayland is so fricking gay, it's got to be a joke by MS meant to kill Linux.