6 ms·

> Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU. X has to do that with DRI and client side rendering too

> Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU. 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.

erik_seaberg 3y ago
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.
- throwawaylinux 3y ago
  > 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. So that doesn't really move the conversation. 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.

erik_seaberg 3y ago

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.

throwawaylinux 3y ago
> 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. So that doesn't really move the conversation. 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.