[GH-ISSUE #29] Remote Desktop Issues #11

New issue

Closed

opened 2026-02-27 15:48:16 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 15:48:16 +03:00

Owner

Originally created by @yankejustin on GitHub (Mar 19, 2015).
Original GitHub issue: https://github.com/quasar/Quasar/issues/29

Already known, but just kept here in case others would like to investigate or propose fixes to these issues with the Remote Desktop feature.

Issues:

Sucks down memory on the Client - Yes, the Garbage Collector will eventually collect the unused resources that have gone astray. However, it does so every second (low-blow to the performance train). It could be very negative to the user if the machine being used is rather poor. The memory allocations will stay around 200MB to 700MB while running the Remote Desktop tool. It will cycle up and down those limits as fast as 3/4 of a second to 1 second...
Issues with multiple monitors:
--> When receiving data of a monitor that is larger than the one you are watching (ex: client has a 1920x1080 monitor and yours is 1080x760) the smaller monitor does not correctly scale the image. This issue is likely due to the way changes are calculated on the client. It causes random pixel anomalies (black pixels, poor resolution in some patches).

Originally created by @yankejustin on GitHub (Mar 19, 2015). Original GitHub issue: https://github.com/quasar/Quasar/issues/29 Already known, but just kept here in case others would like to investigate or propose fixes to these issues with the Remote Desktop feature. Issues: 1) Sucks down memory on the Client - Yes, the Garbage Collector will eventually collect the unused resources that have gone astray. However, it does so every second (low-blow to the performance train). It could be very negative to the user if the machine being used is rather poor. The memory allocations will stay around 200MB to 700MB while running the Remote Desktop tool. It will cycle up and down those limits as fast as 3/4 of a second to 1 second... 2) Issues with multiple monitors: --> When receiving data of a monitor that is larger than the one you are watching (ex: client has a 1920x1080 monitor and yours is 1080x760) the smaller monitor does not correctly scale the image. This issue is likely due to the way changes are calculated on the client. It causes random pixel anomalies (black pixels, poor resolution in some patches).

kerem

2026-02-27 15:48:16 +03:00

closed this issue
added the
bug

help wanted
labels

kerem commented

2026-02-27 15:48:17 +03:00

Author

Owner

@ghost commented on GitHub (Mar 20, 2015):

I worked on this a while ago and believed to had found a long-term fix, however I wanted to get another perspective on how to go about accomplishing this.

I found that calling the Garbage Collector after the send buffer had received the bitmap data would keep the memory usage down greatly. Perhaps there could be something done in this area?

@ghost commented on GitHub (Mar 20, 2015): I worked on this a while ago and believed to had found a long-term fix, however I wanted to get another perspective on how to go about accomplishing this. I found that calling the Garbage Collector after the send buffer had received the bitmap data would keep the memory usage down greatly. Perhaps there could be something done in this area?

kerem commented

2026-02-27 15:48:17 +03:00

Author

Owner

@yankejustin commented on GitHub (Mar 21, 2015):

The problem is that the garbage collector is collecting multiple times a second (around 2-3). This is something that should be avoided. Telling the garbage collector to forcibly collect is not what was intended to be done, but is a fix that is viable but very slow. Telling the Garbage Collector to forcibly collect on all generations for each time the send buffer receives the data would be incredibly slower than letting it leak until the Garbage Collector automagically collects the garbage. The short-term fix is let it leak because the Garbage Collector will get rid of it when it gets bad, but the long-term fix really, really should be to locate the things that are leaking so much and to stop them at the source instead of working around the leak.

@yankejustin commented on GitHub (Mar 21, 2015): The problem is that the garbage collector is collecting multiple times a second (around 2-3). This is something that should be avoided. Telling the garbage collector to forcibly collect is not what was intended to be done, but is a fix that is viable but very slow. Telling the Garbage Collector to forcibly collect on all generations for each time the send buffer receives the data would be incredibly slower than letting it leak until the Garbage Collector automagically collects the garbage. The short-term fix is let it leak because the Garbage Collector will get rid of it when it gets bad, but the long-term fix really, really should be to locate the things that are leaking so much and to stop them at the source instead of working around the leak.

kerem commented

2026-02-27 15:48:17 +03:00

Author

Owner

@yankejustin commented on GitHub (Mar 27, 2015):

I am going to be stepping through the code and I will find the solution to one portion of this bug today. That is, I will fix the memory leaking issues. However, what we need is someone that is skilled with algorithms! We need someone that can take a glance at the algorithm and find out what is causing the lossy-compression with differing monitor resolutions...

@yankejustin commented on GitHub (Mar 27, 2015): I am going to be stepping through the code and I will find the solution to one portion of this bug today. That is, I will fix the memory leaking issues. However, what we need is someone that is skilled with algorithms! We need someone that can take a glance at the algorithm and find out what is causing the lossy-compression with differing monitor resolutions...

kerem commented

2026-02-27 15:48:17 +03:00

Author

Owner

@ghost commented on GitHub (Mar 31, 2015):

I can look into it if you want, made codecs, remote desktops, compression/encryption algorithms etc :)

@ghost commented on GitHub (Mar 31, 2015): I can look into it if you want, made codecs, remote desktops, compression/encryption algorithms etc :)

kerem commented

2026-02-27 15:48:17 +03:00

Author

Owner

@MaxXor commented on GitHub (Mar 31, 2015):

@AnguisCaptor that would be great! I appreciate any solution for this.

@MaxXor commented on GitHub (Mar 31, 2015): @AnguisCaptor that would be great! I appreciate any solution for this.