[Interest] 2017

[Shawn Rutledge]

> On 3 Jan 2017, at 16:19, René J.V. Bertin <rjvbertin at 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.