- 04 Jun, 2010 1 commit
-
-
Joel Martin authored
-
- 03 Jun, 2010 3 commits
-
-
Joel Martin authored
-
Joel Martin authored
From kevinychan/vnc-html5 ebfffdc36.
-
Joel Martin authored
-
- 02 Jun, 2010 3 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
Move DOM manipulation into include/default_controls.js and update vnc.html to use it. Add an example vnc_auto.html which automatically connects using parameters from the query string and doesn't use default_controls.js. Reorder functions in vnc.js to put external interface functions at the top of the RFB namespace.
-
- 01 Jun, 2010 2 commits
-
-
Joel Martin authored
-
Joel Martin authored
In colourMap mode there are 256 colours in a colour palette sent from the server via the SetColourMapEntries message. This reduces the bandwidth by about 1/4. However, appearance can be somewhat less than ideal (pinks instead of gray, etc). It also increases client side rendering performance especially on firefox. Rendering a full 800x600 update takes about 950ms in firefox on my system compared to about 1400ms. Round-trip time for a full frame buffer update is even better on firefox (due to performance of the flash WebSocket emulator). Reduced from about 1800ms to 1100ms on firefox (for 800x600 full update).
-
- 28 May, 2010 3 commits
-
-
Joel Martin authored
Also add a wsencoding test client/server program to test send a set of values between client and server and vice-versa to test encodings. Not turned on by default. Add support for encode/decode of UTF-8 in the proxy. This leverages the browser for decoding the WebSocket stream directly instead of doing base64 decode in the browser itself. Unfortunately, in Chrome this has negligible impact (round-trip time is increased slightly likely due to extra python processing). In firefox, due to the use of the flash WebSocket emulator the performance is even worse. This is because it's really annoying to get the flash WebSocket emulator to properly decode a UTF-8 bytestream. The problem is that the readUTFBytes and readMultiByte methods of an ActionScript ByteArray don't treat 0x00 correctly. They return a string that ends at the first 0x00, but the index into the ByteArray has been advanced by however much you requested. This is very silly for two reasons: ActionScript (and Javascript) strings can contain 0x00 (they are not null terminated) and second, UTF-8 can legitimately contain 0x00 values. Since UTF-8 is not constant width there isn't a great way to determine if those methods in fact did encounter a 0x00 or they just read the number of bytes requested. Doing manual decoding using readUTFByte one character at a time slows things down quite a bit. And to top it all off, those methods don't support the alternate UTF-8 encoding for 0x00 ("\xc0\x80"). They also just treat that encoding as the end of string too. So to get around this, for now I'm encoding zero as 256 ("\xc4\x80") and then doing mod 256 in Javascript. Still doesn't result in much benefit in firefox. But, it's an interesting approach that could use some more exploration so I'm leaving in the code in both places.
-
Joel Martin authored
-
Joel Martin authored
-
- 26 May, 2010 1 commit
-
-
Joel Martin authored
The purpose of the code is to be incorporated into other web projects (whether those are free or not). AGPL prevents combination with other HTML and javascript that is under a weaker (or proprietary) license. Better would be a lesser AGPL, but there is not GNU standard for that. So LGPL-3 meets most of my requirements. If somebody modifies the actual client code and conveys it, then they must release the changes under LGPL-3 also. Add some implementation notes in docs/notes.
-
- 25 May, 2010 2 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
- 20 May, 2010 1 commit
-
-
Joel Martin authored
-
- 17 May, 2010 5 commits
-
-
Joel Martin authored
-
Joel Martin authored
- By dereferencing the 'data' field of the imageData object before the loop, the hextile performance on Chrome is down to 140ms or so for a full 800x600 update. Still have to fall back to Canvas operations for firefox. - Fix RQ empty after reorder bug.
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
- 16 May, 2010 1 commit
-
-
Joel Martin authored
-
- 15 May, 2010 7 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
Fixes: - Make sure that failed state messages stay around until next connect. - Get status message font colors working. - Clear RQ_reorder list on re-connect.
-
Joel Martin authored
- For webkit engines, do array manipulation for each tile subrectangle and only use the array for putImageData after rendering is finished. In Chrome 5.0.375.29 beta, the time to render a full 800x600 hextile image dropped from 500ms to 250ms or so. Firefox 3.5.3 rendering of a full 800x600 hextile image is about 2300ms.
-
Joel Martin authored
- Otherwise client_setting carry over from other connections.
-
- 12 May, 2010 1 commit
-
-
Joel Martin authored
-
- 11 May, 2010 10 commits
-
-
Joel Martin authored
-
Joel Martin authored
-
Joel Martin authored
Pull and modify vnc.css version b747e284c0e417df1599b1d95724518b07be8df6 to include/black.css
-
Joel Martin authored
- Other misc cleanups.
-
Joel Martin authored
- Instead of onload override, move to RFB.load function that takes a parameter for the target DOM ID. This allows the user to have their own onload function. - Add "VNC_" prefix to all element ID names. Only create DOM elements if they don't already exist on the page, otherwise use the existing elements. - Move all styling to separate stylesheet. - Use list model for control styling.
-
Joel Martin authored
-
Joel Martin authored
Instead of selecting on everything every time, only select the writers that we have items queued for. Most of the time the writers are ready so if we select on them even when we don't have anything to send we will fall into a tight loop.
-
Joel Martin authored
Conflicts: wsproxy.py Fix auth mode selection typo.
-
Kevin Chan authored
-
Kevin Chan authored
-