Workaround for potential failure to read the version string if the data isn't already in the buffer. May need further consideration, the problem can't be reproduced with the binary viewer.
Fix an issue where java viewer appears to hang on Mac OS X. As far as I can tell, this is caused by an upstream bug which might be fixed in JDK 7, but for now this gets around the problem without significantly affecting performance.
Fix regression caused by r4841. That patch assumed that JPEG encoding always uses the raw buffer, which is not true. If pixel translation is necessary, then JPEG images will sometimes be encoded from the translated (intermediate) buffer instead.
Replace all stream-based IO with non-blocking NIO-based implementation. Still a fair amount of cleanup to do, particularly in the SSL handler, which is not very robust, and exception handling in general. All core functionality appears to be working fine though.
The Tight encoder uses the pixel buffer as a scratch pad, which doesn't
work so well with the new optimisation to feed it the raw frame buffer.
Reorganise and clean up the code to handle this, and make the raw frame
buffer pointer const so that we might avoid such bugs in the future.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4841 3789f03b-4d11-0410-bbf8-ca57d06f2519
Fix a race condition where we might get updates thrown at us right after a
framebuffer switch, but before we've been given the pointer to the new
framebuffer.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4839 3789f03b-4d11-0410-bbf8-ca57d06f2519
Failure to find FLTK dependencies is only fatal for our version of FLTK.
When using the system version we have to assume it's built the way the
user wants.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4838 3789f03b-4d11-0410-bbf8-ca57d06f2519
Our FLTK patches modified FLTK's autotools-based build system so that HAVE_XFIXES and HAVE_XCURSOR were defined in FLTK's config.h, but those changes never made it into the CMake-based build system used by the in-tree version of FLTK. Further, our build system was allowing silent failures whenever Xft, Xinerama, Xcursor, or Xfixes were not present on the build system. Now, the lack of these libraries is treated as a fatal error, since these libraries are critical for TigerVNC functionality.
Changing the deferred update timer to 10 ms caused a large performance regression on video/3D apps, and until we can quantify the benefits of a larger DUT value, it was decided that it should be changed back to 1 ms for the 1.2 release.
We need to explicitly trigger a framebuffer update for server side rendered
cursors. Previously this happened to work anyway because we had a lot of
triggers for updates. After the cleanup, we need to be more explicit.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4824 3789f03b-4d11-0410-bbf8-ca57d06f2519
Grabbing the RGB components from the BufferedImage one at a time and converting the to a 24bpp RGB color manually is about 25% faster than using BufferedImage.getRGB().
Sync up java Tight decoder with recent changes to C client as much as possible. These changes should also fix the 16bpp issue reported in bug #3429667. I think there are probably errors in the FilterGradient* code but I can't get any servers to actually send this type of data to test it.
Consistent and simple comment header: No need to specify email, since
its included in the meta info below. TigerVNC Team copyright should be
sufficient.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4816 3789f03b-4d11-0410-bbf8-ca57d06f2519
Pierre Ossman
Brian Hinz
DRC
Peter Åstrand