Hi!
Thanks for creating x2go, I'm a big fan!
In the image compression field there has been progress during recent years. Would there be a point to implementing something like jpeg xl in X2Go? As I understand, it compares favorably to standard jpeg and png in every aspect. But perhaps it would not make a big difference or be difficult?
Best,
Pär Larsson, Sweden
Adding new compression is an interesting field, indeed
The underlying nx is prepared structured in a way that make adding additional image compression algorithms quite simple. However, so far we have not implemented any other compression beyond the ones NoMachine already had, making the code very compatible.
On the other hand I am not sure how much we could gain from that. Are 10-20% smaller images worth it? Is that number reasonable at all? Images are cached and only transferred once, if possible. So I guess we should first do some measurements to explore the potential.
Do you have any case where a better image compression could help significantly?
Uli
On Fri, Oct 23, 2020 at 9:46 AM Pär Larsson <par.larsson@umu.se> wrote:
Hi!
Thanks for creating x2go, I'm a big fan!
In the image compression field there has been progress during recent years. Would there be a point to implementing something like jpeg xl in X2Go? As I understand, it compares favorably to standard jpeg and png in every aspect. But perhaps it would not make a big difference or be difficult?
Best,
Pär Larsson, Sweden
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Hi Uli,
No, I'm afraid not. I have limited knowledge of the inner workings x2go so there might indeed be no point in adding more modern compression methods if gui widget elements are cached. But what about other graphcs, such as images in web browsers for example? But perhaps they are not compressed the same way?
Btw: Just read a piece of disturbing news that that Xorg now is more or less abandonware. I guess everyone is expecting Wayland to replace Xorg soon, which is bad news for those of us who rely on remote desktops. This really seems like a giant leap backwards...
//Pär
-----Ursprungligt meddelande----- Från: Ulrich Sibiller <ulrich.sibiller@gmail.com> Skickat: Friday, October 23, 2020 10:46 AM Till: Pär Larsson <par.larsson@umu.se> Kopia: x2go-dev@lists.x2go.org Ämne: Re: [X2Go-Dev] Additional image compression algoritms?
Adding new compression is an interesting field, indeed
The underlying nx is prepared structured in a way that make adding additional image compression algorithms quite simple. However, so far we have not implemented any other compression beyond the ones NoMachine already had, making the code very compatible.
On the other hand I am not sure how much we could gain from that. Are 10-20% smaller images worth it? Is that number reasonable at all? Images are cached and only transferred once, if possible. So I guess we should first do some measurements to explore the potential.
Do you have any case where a better image compression could help significantly?
Uli
On Fri, Oct 23, 2020 at 9:46 AM Pär Larsson <par.larsson@umu.se> wrote:
Hi!
Thanks for creating x2go, I'm a big fan!
In the image compression field there has been progress during recent years. Would there be a point to implementing something like jpeg xl in X2Go? As I understand, it compares favorably to standard jpeg and png in every aspect. But perhaps it would not make a big difference or be difficult?
Best,
Pär Larsson, Sweden
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
On Mon, Oct 26, 2020 at 10:46 AM Pär Larsson <par.larsson@umu.se> wrote:
No, I'm afraid not. I have limited knowledge of the inner workings x2go so there might indeed be no point in adding more modern compression methods if gui widget elements are cached. But what about other graphcs, such as images in web browsers for example? But perhaps they are not compressed the same way?
Applications use X calls to work with images. These calls are interpreted and the image data is compressedn and sent to the other side and cached on both sides. Once the image has been cached subsequent operations on/with the same image will not transfer any image but just contain a hint where to find the image in the cache.
This approach has problems with videos as the images are different every frame and have to be transmitted again. That's the reason videos are sloppy in X2go/NX.
Btw: Just read a piece of disturbing news that that Xorg now is more or less abandonware. I guess everyone is expecting Wayland to replace Xorg soon, which is bad news for those of us who rely on remote desktops. This really seems like a giant leap backwards...
Well, that information's not new. Wayland has been designed for local usage to make full use of the hardware. There's no network awareness built into Wayland. I disregard this development, too.
As long as applications still use the X protocol (and all the toolkits support both X and Wayland) you can still use X2go. It might happen that someone writes an application that is only working on Wayland and will not work with x2go but so far I have not come across such an app (which really means nothing as I have not done any explicit research).
Uli
-
Pär Larsson -
Ulrich Sibiller -
Ulrich Sibiller