Re:Wayland on OpenBSD
by erik_seaberg on Tuesday July 11, 2023 @03:58PM
(#36686482)
It was an architectural mistake to start bypassing GLX and depending on DRI at each app, and Wayland wants to cement that. That’s why we see so many webapps where we would have expected remote windows driven by a backend server; Javascript became the GPU-local end of a lot of opaque rendering protocols to fill the gap.
Re:Wayland on OpenBSD
by throwawaylinux on Wednesday July 12, 2023 @01:55AM
(#36690902)
> It was an architectural mistake to start bypassing GLX and depending on DRI at each app,
1. Well I assert that it was not an architectural mistake. Now we're back to square one. 2. Whether or not it was a mistake, does not change how things are. So you can't really use that as a point against Wayland for X.
> and Wayland wants to cement that. That’s why we see so many webapps where we would have expected remote windows driven by a backend server; Javascript became the GPU-local end of a lot of opaque rendering protocols to fill the gap.
Client side has been driven overwhelmingly by Windows in the past decades though, so I don't see how that is the reason. The number of javascript apps caused by DRI in X must be approximately zero, and caused by Wayland exactly zero.
X has to do that with DRI and client side rendering too, doesn't it?
> As long as Wayland doesn't deliver a remote rendering protocol, the best path forward seems to be shipping Javascript apps to a browser on the end user's machine (where his GPU will be available).
Why does that seem like the best path forward? Seems crazy. For incidental things, admin, etc., software rendering would be fine. The right path forward for a high performance application that needs to ship data to a client that can render it would be to transfer that data, not the drawing of it.