4 ms·

> No, all those can be solved with client libraries. There is no easy way to open a Window and render a string. Period! You either need to write it yourself co

by sprash 4y ago

> No, all those can be solved with client libraries. There is no easy way to open a Window and render a string. Period! You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries" (cairo and freetype do not create Wayland windows and therefore are not applicable here). Look at the code again! If you really think that the code at [1] is in any way a great solution as compared to [2] we are going to disagree. > No, in both modern X11 or Wayland, you should use the same API for screenshots: the XDG screenshot portal. ZERO screenshot apps on X11 use XDG screenshot portal, they all use XGetImage(). Mainly because the assumption that a dbus-daemon is always running everywhere is mostly false. Also XDG screenshot portal is simply not a good solution. It is cumbersome to use, contains tons of edge-cases and pulls a dbus dependency for something that could be solved much simpler with onboard OS-functionality without the need for extra daemons and weird binary protocols > Client-side rendering is also the norm in X11, since decades ago when Xft was released Besides the point, but you are still wrong. Xft does server-side rendering via XRender. The cache is rendered only once on the client but that's a technicality, spline tessellation was supposed to go into the server but Keith Packard had more important things to do at the time.

QUrprUd1nCeicw 4y ago
>There is no easy way to open a Window and render a string. Period! Yes, there is. Use a client library. That's what they're for. >You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries" This is exactly the same as in X11. Remember Xlib is one of those heavy weight client libraries. The X11 example you showed uses Xlib. >Look at the code again! If you really think that the code at [1] is in any way a great solution as compared to [2] we are going to disagree. I don't think either of them are great. I'm saying that's comparing apples to oranges. >ZERO screenshot apps on X11 use XDG screenshot portal, they all use XGetImage(). They shouldn't. Like most parts of X11, XGetImage is an obsolete API. You don't want to use that in modern clients. >Mainly because the assumption that a dbus-daemon is always running everywhere is mostly false. No, dbus is used by basically all modern desktop environments on Linux. If you don't have dbus available you're going to have a lot more problems running normal Linux apps than just dealing with the differences between X11 and Wayland. >Also XDG screenshot portal is simply not a good solution. It is cumbersome to use, contains tons of edge-cases and pulls a dbus dependency for something that could be solved much simpler with onboard OS-functionality without the need for extra daemons and weird binary protocols X11 is also one of those weird binary protocols that isn't onboard OS-functionality and has more edge-cases, so according to this XGetImage isn't a good solution either. >Xft does server-side rendering via XRender. No, you've got rendering mixed up with compositing. With Xft, the rendering of font data to pixels is still done in the client. XRender, despite the name, is frequently only used to composite surfaces together. That's doing the same thing that Wayland is doing.
- sprash 4y ago
  [flagged]
  - QUrprUd1nCeicw 4y ago
    >The Glyphs themselves are rendered only once client side. That's literally what I just said? The glpyhs get rendered client side and then composited in the server. >What is your agenda? I truly don't understand. I don't have an agenda. Do you have to assume everyone has one? Please just take my comments at face-value.
- forgotpwd16 4y ago
  >XGetImage is an obsolete API. You don't want to use that in modern clients. How is obsolete and what makes XDG portal a better option?
  - QUrprUd1nCeicw 4y ago
    X11 APIs have no security and they don't work in Wayland. Either one of those reasons is enough to avoid using them. Aside from that, it's the slowest and worst possible option in X11 because it copies the pixels into the socket. To handle large images you want to at least use MIT-SHM. XGetImage should only be used as a fallback. Or better, just don't use X11 APIs at all.
kaba0 4y ago
That’s just optimizing for the wrong thing. Why should it be easy to write from zero a “hello world” window? Where would you go from there, what’s useful about that? Should it also handle inputs, redraws, widgets, layouting?
- sprash 4y ago
  [flagged]
  - kaba0 4y ago
    That tinfoil hat looks good on you! What the hell does this have to do with user experience? Dev experience? Compared to what exactly? You have 10 hello world windows floating around or what are you talking about? X11 and the whole desktop linux world is a huge vulnerability, not letting a random install script/dev tool become trivially a keylogger is not security theater. vsync is not mandatory, you know that right? It can be controlled by an app, e.g. games can control it themselves. Outside of that, why would you want tearing?! Worse performance? Is that why embedded systems actually prefer wayland solutions over literally embedding a huge monolith? It has as many functionality as you implement.. I’m fairly sure that a bug in xserver will bring down the whole system. There is nothing inherent in wayland demanding a monolithic approach, you can have a server maintaining connections to clients and a plugin that handles the window management part that can be restarted. You managed to not have a single valid point, congrats!
    - dTal 4y ago
      >why would you want tearing?! Avoiding tearing inevitably involves adding latency (the data is ready, render half a frame now or wait for vsync?) Some might consider it worthwhile to give up frame-perfection in exchange for getting as much data to the user as fast as possible; that's valid. Latency isn't just important for games, it colors every interaction we have with the computer.
      - QUrprUd1nCeicw 4y ago

by sprash 4y ago

QUrprUd1nCeicw 4y ago

>There is no easy way to open a Window and render a string. Period! Yes, there is. Use a client library. That's what they're for. >You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries" This is exactly the same as in X11. Remember Xlib is one of those heavy weight client libraries. The X11 example you showed uses Xlib. >Look at the code again! If you really think that the code at [1] is in any way a great solution as compared to [2] we are going to disagree. I don't think either of them are great. I'm saying that's comparing apples to oranges. >ZERO screenshot apps on X11 use XDG screenshot portal, they all use XGetImage(). They shouldn't. Like most parts of X11, XGetImage is an obsolete API. You don't want to use that in modern clients. >Mainly because the assumption that a dbus-daemon is always running everywhere is mostly false. No, dbus is used by basically all modern desktop environments on Linux. If you don't have dbus available you're going to have a lot more problems running normal Linux apps than just dealing with the differences between X11 and Wayland. >Also XDG screenshot portal is simply not a good solution. It is cumbersome to use, contains tons of edge-cases and pulls a dbus dependency for something that could be solved much simpler with onboard OS-functionality without the need for extra daemons and weird binary protocols X11 is also one of those weird binary protocols that isn't onboard OS-functionality and has more edge-cases, so according to this XGetImage isn't a good solution either. >Xft does server-side rendering via XRender. No, you've got rendering mixed up with compositing. With Xft, the rendering of font data to pixels is still done in the client. XRender, despite the name, is frequently only used to composite surfaces together. That's doing the same thing that Wayland is doing.

sprash 4y ago
[flagged]
- QUrprUd1nCeicw 4y ago
  >The Glyphs themselves are rendered only once client side. That's literally what I just said? The glpyhs get rendered client side and then composited in the server. >What is your agenda? I truly don't understand. I don't have an agenda. Do you have to assume everyone has one? Please just take my comments at face-value.
forgotpwd16 4y ago
>XGetImage is an obsolete API. You don't want to use that in modern clients. How is obsolete and what makes XDG portal a better option?
- QUrprUd1nCeicw 4y ago
  X11 APIs have no security and they don't work in Wayland. Either one of those reasons is enough to avoid using them. Aside from that, it's the slowest and worst possible option in X11 because it copies the pixels into the socket. To handle large images you want to at least use MIT-SHM. XGetImage should only be used as a fallback. Or better, just don't use X11 APIs at all.

kaba0 4y ago

That’s just optimizing for the wrong thing. Why should it be easy to write from zero a “hello world” window? Where would you go from there, what’s useful about that? Should it also handle inputs, redraws, widgets, layouting?

sprash 4y ago
[flagged]
- kaba0 4y ago
  That tinfoil hat looks good on you! What the hell does this have to do with user experience? Dev experience? Compared to what exactly? You have 10 hello world windows floating around or what are you talking about? X11 and the whole desktop linux world is a huge vulnerability, not letting a random install script/dev tool become trivially a keylogger is not security theater. vsync is not mandatory, you know that right? It can be controlled by an app, e.g. games can control it themselves. Outside of that, why would you want tearing?! Worse performance? Is that why embedded systems actually prefer wayland solutions over literally embedding a huge monolith? It has as many functionality as you implement.. I’m fairly sure that a bug in xserver will bring down the whole system. There is nothing inherent in wayland demanding a monolithic approach, you can have a server maintaining connections to clients and a plugin that handles the window management part that can be restarted. You managed to not have a single valid point, congrats!
  - dTal 4y ago
    >why would you want tearing?! Avoiding tearing inevitably involves adding latency (the data is ready, render half a frame now or wait for vsync?) Some might consider it worthwhile to give up frame-perfection in exchange for getting as much data to the user as fast as possible; that's valid. Latency isn't just important for games, it colors every interaction we have with the computer.
    - QUrprUd1nCeicw 4y ago