[Interest] 2017

René J.V. Bertin rjvbertin at gmail.com
Tue Jan 3 16:19:27 CET 2017


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 ;)

>But then, if Wayland will eventually make X11 obsolete, that will be impractical at some point, right?  Besides the fact that X11-over-network doesn’t work well with every application anyway.  (The best applications for that are old-school: using X resources sparingly and reusing them properly, sending text across and asking the X server to render it, and so on.  Qt hasn’t been optimized for that in ages.) 

Actually, you can even do animations over the network with pure X, but that requires some setting up (sending pre-calculated images before animating them). Simple vector graphics works fine, too.

>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.

>Oh well, maybe X11 will realistically be around for another couple of decades anyway.

Very likely, esp. if Wayland doesn't implement a good remote protocol.

>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?

>> Shawn, do you think it's worth reporting this on the bug tracker? I would guess that the same happens however you make an icon theme available, be it through an embedded resource or an XDG-style icon directory, no?
>
>Sure, but it will get triaged to a pretty low priority if it only affects this unusual setup of yours.

I'm not sure. I would expect that it affects any application that provides an icon theme in an embedded resource even though I see no sign of it in Kevin's screenshot. I certainly do not patch any code to add icons explicitly do dialog buttons so any icons that show up in those buttons are the result of default icon lookups  that all of a sudden return a non-empty icon.

>But anyone can write a patch for it anyway, especially if the fix is straightforward and doesn’t break anything.

I'd have to look how complicated it would be (and that doesn't have a very high priority for me either) but it would basically be respecting the dialog-buttons-have-icons attribute. AFAIK the attribute is set to Off on Mac, so respecting it in the appropriate locations shouldn't make any difference under normal circumstances. My guess is that identifying the appropriate locations will be more time-consuming than writing the patch.

R.



More information about the Interest mailing list