[prev in list] [next in list] [prev in thread] [next in thread] 

List:       osflash-fvnc
Subject:    [FVNC] Major FVNC changes
From:       darron () darronschall ! com (Darron J !  Schall)
Date:       2007-03-09 17:01:39
Message-ID: 45F192F3.3060205 () darronschall ! com
[Download RAW message or body]

Hi list,

Over the past few weeks I've been silently working on increasing the 
performance of FVNC.  I'm happy to announce that I was able to 
dramatically improve rendering speed, as well as majorly reduce required 
CPU and memory usage.  It all boiled down to coming up with an 
intelligent way to handle the asynchronous nature of the 
flash.net.Socket class. 

Previously, my approach was this:
Copy the socket data into a buffer.  Try to read a server message from 
the buffer, hit an EOFError when not enough data was available.  Reset 
the buffer to the beginning, wait until more socket data arrived, try 
again to process a complete message.

The new approach is this:
When socket data arrives, build a parse tree that starts creating server 
messages.  If not enough data is avaialble, no big deal.  The parse tree 
saves what is was working on last, and when data arrives again it picks 
up where it left off.  On every "enter frame" of the Flash Player (when 
screen draws happen), check to see if any messages have completed, and 
if so then update the display.

The new approach is dramatically better in terms of speed and 
resources.  I can't stress enough just how much better it performed in 
my local testing -- it's like an entirely new application.  I hope you 
enjoy the changes!

Below is the latest from the commit log for reference.  The good stuff 
is in revision [7] 
<https://mirror1.cvsdude.com/trac/osflash/fvnc/changeset/7>.

All the best,

-d

===[ Begin commit log message ]===

Major changes to how the RFB protocol is handled. This version is much 
better at dealing with the asynchronous nature of the flash.net.Socket 
connection. It is able to process data as it arrives, and pick up where 
it left off in the event that not enough data is available to complete a 
server message. Overall, this indirectly fixes #3 
<https://mirror1.cvsdude.com/trac/osflash/fvnc/ticket/3>.

The results is much lower memory requirements (no seconday buffer 
required, no buffer growing out of control, no code to keep buffer size 
relatively small, etc). Also, CPU usage has decreased dramatically 
because there is no busy waiting or repeat work done (trying to parse a 
compelte message from the beginning every time data arrived).

Fixed a few minor bugs as well:

    * Fit to screen now keeps the correct aspect ratio
    * Probably some more...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/fvnc_osflash.org/attachments/20070309/e5b8ff49/attachment.htm

[prev in list] [next in list] [prev in thread] [next in thread]