> On 3 Jan 2017, at 16:19, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Tuesday January 3 2017 13:57:51 Shawn Rutledge wrote: > >>> As to remote use: I thought that wasn't the point of Wayland at all? >> >> They keep saying to go on using X11 or VNC or whatever existing solution you >> like. > > They could implement their own VNC compositor then ;)
If nobody has done that yet, it’s quite predictable that someone will pretty soon. (googles) ok maybe https://github.com/RealVNC/wayland-developer-preview but I haven’t tried it... >> Personally I think a good eventual solution would be to leverage the >> application server's GPU (the client machine in X terminology) both for >> rendering and for compression, and send compressed frames (or frame diffs) >> over the network, using some compression technique which both runs well on >> the GPU and is as close to lossless as possible. But it won’t scale to lots >> of users either, if the GPU usage ends up being too high. > > That sounds reasonable. It bit far from the original topic, but who cares :) > As to GPU usage: one important and vocal class of users doing remote > displaying (*with* OpenGL if you please) are scientists who do heavy > calculation on big headless clusters. I don't think local GPU usage is an > issue for them. Right, but frame rate and bandwidth and latency do matter. It’s a different use case anyway. I guess some combination of Wayland + OpenGL could be sent across the network in the same way as X11 + GLX can be, but when googling about remote Wayland it looks like people seem to think mainly of sending pre-rendered frames. Both could be useful depending on speed and latency of the network and availability of the local GPU. >> Another alternative of course is to use some other client-server protocol >> such that only the “model” of MVC is on the server, and UI rendering >> instructions are sent across the network instead of actual rendered >> graphics. > > Erm, that's what X11 does traditionally, no? No, because you can’t send any complete objects from the view layer across to the X server. When you write the view in an OO language you’d probably include some imperative code to assemble the widgets and to handle low-level events and to fetch and format values from the model - it's more than just the elements which are rendered. X protocol is not programmable. (OTOH anything that is programmable is exploitable, so I guess that’s why X servers aren’t known for having security holes left and right like browsers do.) https://en.wikipedia.org/wiki/X_Window_System says "X also lacks native support for user-defined stored procedures on the X server, in the manner of NeWS – there is no Turing-complete scripting facility.” Exactly - NeWS was based on Postscript, so it was superior in this regard. (At some point ages ago, I tentatively started a little project to recreate something like NeWS, but didn’t get very far before I realized I’m not so fond of stack-based languages that I want to write a lot of code that way, despite having used Postscript in anger on more than one occasion. ;-) And nowadays a stack-based language is not the highest-performing VM that you could build upon, if you want to translate some other language to it. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
