Regarding the time between screen frames

Topics: News
Coordinator
Apr 25, 2013 at 5:31 PM
Hello everybody,

I have started this thread to explain to you why the time between sent frames from the screen is so big (between 1 and 5 minutes), making NVNC (for the time being) practically unusable.

The issue is not that the sockets are slow, or that the encoding of the frames is slow. The factor that slows things down is the amount of data.
RFB Encodings use byte array representation of the screen pixels, and the standard ones do not support image compression. For example, a bitmap screenshot of my resolution (1366x768) is around 5MB, whereas a jpeg screenshot would be 100-200KB. Since the standard RFB Encodings (Raw, Hextile, RRE) do not support image compression, the byte data that needs to be transferred to the client is the same as the bitmap size (in my case 5MB).
Sending 5MB of data through a Socket is indeed slow.

At the moment, I am working on two things:
  • Implementing the ZRLE Encoding, which uses Zlib algorithm to compress the data
  • Selective screen updates
Now, ZRLE is my priority, and I will try to finish it as fast as possible, to make NVNC practically usable. But, it is a fairly complicated algorithm, so it might take me some time.
On the other hand, the selective screen updates algorithm, will allow the server to send to the client only areas of the screen which have changed since the last sent frame.
That will make the server send even less data, and not an image of the whole screen.

That is all regarding this issue,
T1T4N
Apr 28, 2013 at 11:16 AM
Edited Apr 28, 2013 at 11:18 AM
t1t4n: we understand the situation, and hope next release will be online soon.
also, I want to thanks your effort and support.
about compression, I think a faster solution can be send selective data technique.
if you can divide the screen in 64 subscreens, and send only the portion of the screen that changes, you can solve it in a simple and faster way, without the complexity of compression impementation.
this mechanism is something that you will need to implement sooner or later, beyon having compression.
Talking about efficiency, there's no need to send the entire screen if only 20% has changes., even if compression is available.
so, if you need to implement this technique sooner or later, why wait ?
you can implement screen division easily, reduce the time frame effect to 20% approx if my maths are right, and then continue with the real and definitive solution implementing compression algorithms.
screen division can be implemented in a few hours, and make the server more stable and usable.....
is just an idea, hope it helps.
thanks again for your tremendous work.
Coordinator
Apr 28, 2013 at 1:21 PM
@crosemffet: The ZRLE Encoding, which uses compression, is a MUST.
The tests I have done, are showing reduce in size when compressed.
For example, on my screen size, uncompressed data is 5MB, but compressed with Zlib it is just 200KB.
The selective update algorithm will me implemented once I have the ZRLE encoding finished.