Oh I see how maybe that could of been misunderstood. wm4 barely wrote shit for wayland. I, however, have written plenty. It's a pretty gimped API in comparison to xlib/xcb. It sucks.
doing it wrong, most xlib shit moved into client code
2 years ago
Anonymous
I'm not sure what you mean here (toolkits?). It doesn't really change my point though.
>could of
Frick I'm a moron.
2 years ago
Anonymous
>I'm not sure what you mean here (toolkits?)
libraries like xkbcommon, freetype, cairo, harfbuzz, libportal, or just dbus
2 years ago
Anonymous
That's not a replacement for drawing windows on the screen which is what I like to do. Even if you use some other library that abstracts it away, it's not going to change the fact that its wayland implementation is likely gimped in comparison to the x11 one. For example, compare fractional scaling of fonts on QT with X11 and wayland (the latter is blurry and shit).
2 years ago
Anonymous
>That's not a replacement for drawing windows on the screen which is what I like to do
uhh yeah it is that's what cairo does and it works the same on both
2 years ago
Anonymous
Cairo is nice but that's 2D only.
2 years ago
Anonymous
opengl is the same on x and wayland too
2 years ago
Anonymous
No it's not. It's not even close to the same. You're going to have to completely rewrite your renderloop for wayland simply because it's a special snowflake.
2 years ago
Anonymous
>You're going to have to completely rewrite your renderloop for wayland
lolo what, you trolling or just stupid
2 years ago
Anonymous
>he doesn't know about the ass moronic frame callback and indefinite blocking egl behavior
wew lad
2 years ago
Anonymous
Explain.
2 years ago
Anonymous
>he doesn't know how to work around that in 3 lines of code
kek
2 years ago
Anonymous
SDL, QT, etc. has issues with it too and so does basically everyone else.
Explain.
Wayland developers absolutely hate internally driven renderloops for some arbitrary reason. Note that this is a common, sensible design for applications that run on multiple platforms so you can have one consistent, internal API to handle everything. The "proper" way to draw on wayland is to wait for the compositor to send you back a frame event. This is fine in and of itself. The problem comes later. First, a swap interval of 1 in opengl (i.e. vsync) will indefinitely block the application if it is hidden in some way (i.e. doesn't receive frame callback). This is how it is implemented in Mesa (FIFO in vulkan also works like this). Secondly, applications in wayland have no way of knowing whether they are hidden or not. So the only way to "properly" draw is to do it in the frame callback. This is a very inflexible design compared to literally everyone else that just lets you do a normal block on vsync. It causes problems.
2 years ago
Anonymous
This sounds so moronic that I have trouble figuring out whether I'm being baited or that's how Wayland actually works.
2 years ago
Anonymous
I wish I was making this up.
https://emersion.fr/blog/2018/wayland-rendering-loop/
2 years ago
Anonymous
>the article enthusiastically presents it as a good thing
Tell me this is an elaborate prank, please.
2 years ago
Anonymous
>SDL, QT, etc. cant write 3 lines of code
KEK
2 years ago
Anonymous
>Wayland developers absolutely hate internally driven renderloops for some arbitrary reason.
It's not an arbitrary reason. Toolkits can't use internally driven renderloops without causing huge inefficiencies. There shouldn't be any blocking in a toolkit. >Note that this is a common, sensible design for applications that run on multiple platforms so you can have one consistent, internal API to handle everything.
It's not a sensible design unless you want it to be wrong on every platform. > First, a swap interval of 1 in opengl (i.e. vsync) will indefinitely block the application if it is hidden in some way (i.e. doesn't receive frame callback).
This is legal and allowed by the OpenGL spec. >Secondly, applications in wayland have no way of knowing whether they are hidden or not.
You don't need to know if you're hidden to unblock the loop. >So the only way to "properly" draw is to do it in the frame callback.
No you can do your own timing to draw properly. The frame callback is just a hint if you want your animation to be smooth. >This is a very inflexible design compared to literally everyone else that just lets you do a normal block on vsync.
No it's not, just unblock yourself on vsync periodically if it becomes a problem. >It causes problems.
Not if you can code.
This sounds so moronic that I have trouble figuring out whether I'm being baited or that's how Wayland actually works.
You're being baited. Anon is uninformed and trolling.
>My VLC uses a QT OpenGL widget to play back video
No it uses libplacebo. Please stop anon.
>No it uses libplacebo. Please stop anon.
https://wiki.videolan.org/Video_output/#glx.2C_opengl
?
I wish I was making this up.
https://emersion.fr/blog/2018/wayland-rendering-loop/
>the article enthusiastically presents it as a good thing
Tell me this is an elaborate prank, please.
That's an example of the simplest possible event loop.
2 years ago
Anonymous
That wiki is outdated. VLC uses libplacebo for rendering by default and has for a long time. Also that link only shows that it used glx and says nothing about using QT for playing back video (this is obviously moronic I'm not sure why you're still trying to argue this is true). You can stop pretending anytime.
2 years ago
Anonymous
>VLC uses libplacebo for rendering by default and has for a long time.
https://code.videolan.org/videolan/libplacebo/-/tree/master/src/opengl
? >this is obviously moronic I'm not sure why you're still trying to argue this is true
https://code.videolan.org/videolan/vlc/-/blob/master/modules/gui/qt/maininterface/compositor_dcomp_uisurface.cpp
? >You can stop pretending anytime.
?
>maininterface/compositor_dcomp_uisurface.cpp
The GUI parts use QT. You can see that the actual drawing is done using GL or D3D calls. You can figure this out if you look at it for two seconds.
2 years ago
Anonymous
>https://code.videolan.org/videolan/vlc/-/blob/master/configure.ac#L3074
? >You can see that the actual drawing is done using GL
This is what I just said. Are you baiting?
2 years ago
Anonymous
Okay we're done here. I'm not wasting my time anymore with your stupid ass.
2 years ago
Anonymous
>no arguments >adhominem
The hallmark of the shill, thanks for playing.
2 years ago
Anonymous
haha thanks I feel remoralized. Truth and beauty prevail against abomination
>wm4 barely wrote shit for wayland
That's not quite true. In fact, wm4 was the one who initially merged Wayland support in mpv in the first place. He hated it with a passion, yes, but he did write Wayland client code.
2 years ago
Anonymous
wm4 merged wayland code and never got in the way of people developing it or anything, but he didn't actually maintain it that much. It was always other people. He mainly only cared about X11.
I've written lots of client code for both. Wayland is better. X is worse.
>wm4 barely wrote shit for wayland
That's not quite true. In fact, wm4 was the one who initially merged Wayland support in mpv in the first place. He hated it with a passion, yes, but he did write Wayland client code.
Mpv shouldn't even have a wayland backend. All other movie players use a toolkit, the mpv developers are just masochists who get off on code duplication.
>toolkit for playing video
you are a special moron my friend. Way to show you LARP this fast.
2 years ago
Anonymous
>no arguments >adhominem
Please explain why all other video players use a toolkit then? Is VLC doing something wrong because it has a menu instead of making you use cryptic keybinds like mpv?
2 years ago
Anonymous
VLC doesn't use QT to actually playback video friend. It shows a menu and shit. Use your brain a little bit.
2 years ago
Anonymous
My VLC uses a QT OpenGL widget to play back video. It doesn't need to call X or Wayland. You use your brain a little bit, learn how Qt works.
2 years ago
Anonymous
>My VLC uses a QT OpenGL widget to play back video
No it uses libplacebo. Please stop anon.
>wm4 barely wrote shit for wayland
That's not quite true. In fact, wm4 was the one who initially merged Wayland support in mpv in the first place. He hated it with a passion, yes, but he did write Wayland client code.
opengl is the same on x and wayland too
No it's not. It's not even close to the same. You're going to have to completely rewrite your renderloop for wayland simply because it's a special snowflake.
I've written lots of client code for both. Wayland is better. X is worse.
[...]
Mpv shouldn't even have a wayland backend. All other movie players use a toolkit, the mpv developers are just masochists who get off on code duplication.
because I like being keylogged
wm4 hated wayland and he was right
>t. has written more wayland client code than probably 99% of IQfy
wm4 can't code his way out of a paper bag
Oh I see how maybe that could of been misunderstood. wm4 barely wrote shit for wayland. I, however, have written plenty. It's a pretty gimped API in comparison to xlib/xcb. It sucks.
doing it wrong, most xlib shit moved into client code
I'm not sure what you mean here (toolkits?). It doesn't really change my point though.
Frick I'm a moron.
>I'm not sure what you mean here (toolkits?)
libraries like xkbcommon, freetype, cairo, harfbuzz, libportal, or just dbus
That's not a replacement for drawing windows on the screen which is what I like to do. Even if you use some other library that abstracts it away, it's not going to change the fact that its wayland implementation is likely gimped in comparison to the x11 one. For example, compare fractional scaling of fonts on QT with X11 and wayland (the latter is blurry and shit).
>That's not a replacement for drawing windows on the screen which is what I like to do
uhh yeah it is that's what cairo does and it works the same on both
Cairo is nice but that's 2D only.
opengl is the same on x and wayland too
No it's not. It's not even close to the same. You're going to have to completely rewrite your renderloop for wayland simply because it's a special snowflake.
>You're going to have to completely rewrite your renderloop for wayland
lolo what, you trolling or just stupid
>he doesn't know about the ass moronic frame callback and indefinite blocking egl behavior
wew lad
Explain.
>he doesn't know how to work around that in 3 lines of code
kek
SDL, QT, etc. has issues with it too and so does basically everyone else.
Wayland developers absolutely hate internally driven renderloops for some arbitrary reason. Note that this is a common, sensible design for applications that run on multiple platforms so you can have one consistent, internal API to handle everything. The "proper" way to draw on wayland is to wait for the compositor to send you back a frame event. This is fine in and of itself. The problem comes later. First, a swap interval of 1 in opengl (i.e. vsync) will indefinitely block the application if it is hidden in some way (i.e. doesn't receive frame callback). This is how it is implemented in Mesa (FIFO in vulkan also works like this). Secondly, applications in wayland have no way of knowing whether they are hidden or not. So the only way to "properly" draw is to do it in the frame callback. This is a very inflexible design compared to literally everyone else that just lets you do a normal block on vsync. It causes problems.
This sounds so moronic that I have trouble figuring out whether I'm being baited or that's how Wayland actually works.
I wish I was making this up.
https://emersion.fr/blog/2018/wayland-rendering-loop/
>the article enthusiastically presents it as a good thing
Tell me this is an elaborate prank, please.
>SDL, QT, etc. cant write 3 lines of code
KEK
>Wayland developers absolutely hate internally driven renderloops for some arbitrary reason.
It's not an arbitrary reason. Toolkits can't use internally driven renderloops without causing huge inefficiencies. There shouldn't be any blocking in a toolkit.
>Note that this is a common, sensible design for applications that run on multiple platforms so you can have one consistent, internal API to handle everything.
It's not a sensible design unless you want it to be wrong on every platform.
> First, a swap interval of 1 in opengl (i.e. vsync) will indefinitely block the application if it is hidden in some way (i.e. doesn't receive frame callback).
This is legal and allowed by the OpenGL spec.
>Secondly, applications in wayland have no way of knowing whether they are hidden or not.
You don't need to know if you're hidden to unblock the loop.
>So the only way to "properly" draw is to do it in the frame callback.
No you can do your own timing to draw properly. The frame callback is just a hint if you want your animation to be smooth.
>This is a very inflexible design compared to literally everyone else that just lets you do a normal block on vsync.
No it's not, just unblock yourself on vsync periodically if it becomes a problem.
>It causes problems.
Not if you can code.
You're being baited. Anon is uninformed and trolling.
>No it uses libplacebo. Please stop anon.
https://wiki.videolan.org/Video_output/#glx.2C_opengl
?
That's an example of the simplest possible event loop.
That wiki is outdated. VLC uses libplacebo for rendering by default and has for a long time. Also that link only shows that it used glx and says nothing about using QT for playing back video (this is obviously moronic I'm not sure why you're still trying to argue this is true). You can stop pretending anytime.
>VLC uses libplacebo for rendering by default and has for a long time.
https://code.videolan.org/videolan/libplacebo/-/tree/master/src/opengl
?
>this is obviously moronic I'm not sure why you're still trying to argue this is true
https://code.videolan.org/videolan/vlc/-/blob/master/modules/gui/qt/maininterface/compositor_dcomp_uisurface.cpp
?
>You can stop pretending anytime.
?
idiot
https://code.videolan.org/videolan/vlc/-/blob/master/configure.ac#L3074
>maininterface/compositor_dcomp_uisurface.cpp
The GUI parts use QT. You can see that the actual drawing is done using GL or D3D calls. You can figure this out if you look at it for two seconds.
>https://code.videolan.org/videolan/vlc/-/blob/master/configure.ac#L3074
?
>You can see that the actual drawing is done using GL
This is what I just said. Are you baiting?
Okay we're done here. I'm not wasting my time anymore with your stupid ass.
>no arguments
>adhominem
The hallmark of the shill, thanks for playing.
haha thanks I feel remoralized. Truth and beauty prevail against abomination
>could of
>wm4 barely wrote shit for wayland
That's not quite true. In fact, wm4 was the one who initially merged Wayland support in mpv in the first place. He hated it with a passion, yes, but he did write Wayland client code.
wm4 merged wayland code and never got in the way of people developing it or anything, but he didn't actually maintain it that much. It was always other people. He mainly only cared about X11.
Wayland fans are nocoders. Literally anyone who actually deals with Wayland quickly realizes just how bad it is.
X sucks, yes, but somehow those geniuses managed to come up with something even worse.
I've written lots of client code for both. Wayland is better. X is worse.
Mpv shouldn't even have a wayland backend. All other movie players use a toolkit, the mpv developers are just masochists who get off on code duplication.
Did Collabora fire you, Scott?
>toolkit for playing video
you are a special moron my friend. Way to show you LARP this fast.
>no arguments
>adhominem
Please explain why all other video players use a toolkit then? Is VLC doing something wrong because it has a menu instead of making you use cryptic keybinds like mpv?
VLC doesn't use QT to actually playback video friend. It shows a menu and shit. Use your brain a little bit.
My VLC uses a QT OpenGL widget to play back video. It doesn't need to call X or Wayland. You use your brain a little bit, learn how Qt works.
>My VLC uses a QT OpenGL widget to play back video
No it uses libplacebo. Please stop anon.
I hate the future
Because it's the present, where wayland doesn't fricking work.
X11 also doesn't work.
>senseless mass replier bot post
thank you gpt-IQfy
i'm not a bot i'm doing this for fun
moron
The future isn't here yet
Because of KDE showstoppers