Discuss keithp's suggestions

[uli42]

Here's a chat excerpt about sunweavers talk to Keith Packard. This issue can be used to discuss his suggestions and maybe open additional issues.

(01:33:05) sunweaver: uli42: Ionic: I had a talk with keithp today. (01:33:12) sunweaver: He mentioned various ideas... (01:33:39) sunweaver: 1. he thinks that GLX is simply too slow with Mesa soft on remote connections and he would seriously drop GLX support. (01:34:26) sunweaver: I don't second that... But... in X2Go GLX gets disabled by default, so you simply can't use applications that require GLX. Maybe the clean approach. But I am reluctant to remove what we have. (01:35:27) sunweaver: 2. keithp suggested to investigate on how Composite backend requests are handled in nxcomp. He suggests to send over all the XPixmaps over nxcomp and then do the Compositing on the client side in nxproxy. This certainly is a really good idea. (01:35:46) sunweaver: 3. Also he queried, if nxcomp fully supports RENDER up to its latest version. (01:36:11) sunweaver: and I currently wonder, if the missing glyphs may also be caused in nxcomp. (01:36:28) sunweaver: @Ionic: did you test nxagent as nested X server? or over nxcomp. (01:38:03) sunweaver: 4. he said, instead of backporting all our stuff, he would simply drop nxagent into the X.org Xserver and tree and simply make it build (01:38:43) sunweaver: 5. he would move all NX_X11 transport related stuff into nxagent, use libX11's drawing commands and simply drop libNX_X11. (01:38:54) sunweaver: I had been working a while back on a similar approach, but failed. (01:39:01) sunweaver: I'll maybe pick that up again. (01:39:45) sunweaver: 6. also he would spend a couple of days on investigating if "nxagent" could simply be redone based on the generic xfree86 driver stack. (01:40:34) sunweaver: ajax, he said, is very keen on getting rid of all other implementations (XEphyr, Xnest, Xwayland) and turn all of that into something based on hw/xfree86. (01:41:08) sunweaver: 7. and he said, we cannot expect support from X.org devs (he guesses) for old Xserver code. (01:41:38) sunweaver: 8. on the other hand, integration into recent X.org is highly welcome, modifications to the build scripts will be accepted and such. (01:41:53) sunweaver: only the nxagent code needs to be shipped externally and pulled in via a git submodule or such. (02:13:01) Ionic: 1.) might be slow, but we can't do that. software gradually uses GLX more often, even without checking for its presence and segfaults. see GTK3... (02:14:32) Ionic: 2.) compositing is done server-side IIRC... which kinda makes sense? why would we transfer all pixmaps first and then composite later? the compositing result should be smaller than the individual original pixmaps? (02:15:54) Ionic: 3.) I've only tested nxagent as a nested X server, nxcomp wasn't part of the tests, so that can't be the case unfortunately... but I'd have to retest with the color/triangle changes, maybe it has something to do with that (02:18:19) Ionic: 4.) would work, if hw/nxagent was the only added component... but it isn't, nomachine also changed other places (obviously) (02:20:07) Ionic: 5.) we should drop libNX_X11 at some point, but it's probably not the right time yet (02:23:05) Ionic: 6.) wouldn't that entail reimplementing everything? if they plan to get rid of the other implementations we probably won't have a lot of choices, but I doubt that'll happen too soon (02:23:20) Ionic: 7.) of course not, that's (also) why we try to update our stuff (02:23:46) Ionic: 8.) in due time... (03:34:17) sunweaver: Ionic: about 2. nope. If compositing happens server-side, you transfer every composited combination of the compositing as individual pixmap. (03:34:38) sunweaver: as opposed to transferring all parts of the compositing once and then the compositing commands. (03:39:39) Ionic: hm yeah, but... dunno, like say most of the pixmaps are occluded by others, the compositing result will in this case be much smaller than the individual original pixmaps (03:45:58) Ionic: when thinking about multiple compositing operations though, it may make sense to transfer the original pixmaps at some point... (04:14:31) sunweaver: and when thinking about shadowed windows, fading in menus, etc. (04:14:40) sunweaver: they can grow quite big... (04:14:49) sunweaver: and each fading step is a bitmap. (06:47:27) Ionic: yeah (06:48:23) Ionic: but what happens on normal remote X11 connections? isn't that exactly what they would do? (06:48:28) Ionic: I'm a bit sceptical

[uli42]

1. dropping GLX would mean no current desktop would run
2. Good suggestion. Sending over the pixmaps once and then use the cache might be helpful. For those transfers we must ensure lossless compression.
3. dropping nxagent into Xorg would mean we have to do the backports immediately (and not step by step), otherwise it would not even compile. And we might have to go through adding patches to upstream Xorg which is a process that just takes very long (my impression after looking at the existing backlog...). But we could try comparing our source to the current Xnest and adapt our code (and take that as one or two HUGE steps instead of backporting commit by commit. That could be a quicker path to get close to Xorg HEAD. Were would libNX_X11 go with that approach?
4. dropping libNX_X11 can only be done if nxcomp gets integrated as an own transport into upstream Xorg. I am not sure if extending xtrans is sufficient for that to happen.
5. We should talk to ajax about that an check the limitations of the generic xfree86 driver stack. Can we do everything we need with it? If so, I'd vote for dropping nx compatibility, use another name and redesign the option interface.
6. what Ionic said
7. nor sure why nxagent has to be shipped externally. Is it about the license? Where would nxcomp* and nxproxy go?

[uli42]

Regarding the compostie stuff: We could work out a two-step approach: As long as the required pixmaps have not been transferred to the client side we use composite on the server side and transfer the result. In the background we transfer all pixmaps. As soon as all of them are on the client side we switch to client side compositing. With this things might be slow at the beginning but start to speed up after some time.

But as composite is nor working properly at all we should first come to state where it works server-side and only then extend the client side.