Hello Rahul, Current implementation also splits the picture to the tiles and send only diff (if it is not the keyframe) you can check the code here: https://svn.apache.org/repos/asf/openmeetings/trunk/singlewebapp/src/org/apache/openmeetings/screen/webstart/ScreenV1Encoder.java
The slowest part is image grabbing :( According to your code: 1) it is hard to read since it has no indentation 2) I'm afraid the following code: "if(image[i] != original[i])" will never work as expected. In Java such comparison will always return false if not the same object is passed .... Current implementation uses pixel-by-pixel comparison. According to the ports: I'm afraid specifying the port manually is not an option :( Maybe the task should be changed a bit: 1) the current screen sharing app need to be profiled 2) bottlenecks should be speed up 3) if it is possible image grabbing should be enchanced On Sun, May 5, 2013 at 8:19 AM, rahul bhola <[email protected]> wrote: > hi, > i worked on basic architecture for implementing rfb in openmeetings and > wrote the code as in attachments. i have successfully coded the hextile > encoding as well as decoding class which is one of the key factor that > makes this method faster. Also this code is not entirely according to RFB > specification and i am working to improve on that. currently as i was > unable to add any encryptions hence i left that part in handshake message > also. > the hextile encoder and decoder seems to work fine ,the code is not too > neat at the moment will improve it asap.also i did not add any > specification for ports and user can enter any one but still the default > has been set to 5900 (please let me know if there is problem with this part > i will change it). > the update frame request has been partially implemented on the client > side still working for server side. > please review the code and let me know what changes and upgrades are to > be made > > -- WBR Maxim aka solomax
