DRC [Wed, 12 Oct 2011 19:38:48 +0000 (19:38 +0000)]
Newer versions of GCC (specifically, the one in MinGW64) don't like casting directly from a 64-bit pointer to a 32-bit integer, so we need to first cast to a 64-bit integer (remember that Windows is LLP64)
Brian Hinz [Thu, 6 Oct 2011 06:21:32 +0000 (06:21 +0000)]
More changes to scaling code. Tested on Ubuntu 11.04/OpenJDK and Win7/Sun Java 6u27. Auto, FixedRatio, & % scale all seem to work. Will test on other platforms soon.
DRC [Wed, 5 Oct 2011 21:39:59 +0000 (21:39 +0000)]
The previous fix to the NullPointer issue did not work, because it was simply setting separator to null (not what we want.) Fix the issue properly + fix spelling of "separator".
DRC [Wed, 5 Oct 2011 21:28:03 +0000 (21:28 +0000)]
Launch vncconfig directly from vncserver, not from xstartup. Justification: vncconfig is necessary to enable basic functionality of the TigerVNC system (clipboard transfer, most notably.) It isn't always going to be in the PATH, and in fact, there might be more than one version of it on the system (for instance, a version from RealVNC in /usr/bin and a version from TigerVNC in /opt/TigerVNC/bin.) If it is desirable to disable vncconfig under certain circumstances, then I would suggest adding a command-line option to vncserver to accomplish that.
Brian Hinz [Wed, 5 Oct 2011 03:45:43 +0000 (03:45 +0000)]
More fixes for bug #3418256. Copied jarsigning routine from TurboVNC in order to produce a signed applet so the system clipboard can be accessed from when used in applet mode. These changes will need some testing to make sure that there aren't any corner-cases where something breaks.
Brian Hinz [Tue, 4 Oct 2011 23:53:01 +0000 (23:53 +0000)]
Fixes for bug #3418258. Cleans up all of the 'unchecked' and 'deprecated' linter warnings. Several of the redundant casts have been intentionally left for clarity. Set '-serial' and '-cast' linter flags to reduce the number of warnings (it should be safe to ignore serial because the end product is a jar rather than individual class files. AFAIK, there is no performance penalty for redundant casts in Java). If anyone objects to the linter flags they can be removed (the linter flags, that is).
DRC [Tue, 4 Oct 2011 06:57:19 +0000 (06:57 +0000)]
Always look for the Java classes in ../vnc/classes first before looking in the system locations. This prevents TigerVNC from picking up the Java classes from a RealVNC installation.
DRC [Tue, 4 Oct 2011 02:09:13 +0000 (02:09 +0000)]
Re-commit MSVC build fixes, which were forcibly removed by 4675. Please (a) bring these upstream so they don't get deleted again, and (b) always check the build with MSVC prior to committing modifications to any libraries that affect that build.
DRC [Sat, 1 Oct 2011 19:13:12 +0000 (19:13 +0000)]
Disable Composite extension by default in the legacy-friendly TigerVNC build. Justification: Some older versions of Gnome do not work properly when Composite is enabled. This is known to be a problem with RHEL 4 (Gnome 2.8), and it causes the legacy-friendly build to be unusable on that platform. Newer Gnome versions, such as 2.16.0 (the version in RHEL 5), work properly with Composite enabled, but those versions don't support compositing anyhow, so it doesn't matter if we remove the extension. Typically, platforms that are new enough to support compositing are also new enough to not require the legacy-friendly build of TigerVNC. Further, Composite can be re-enabled by simply adding --enable-composite to the XORGCFGFLAGS env. variable prior to executing 'build-xorg build'.
Pierre Ossman [Fri, 30 Sep 2011 12:54:24 +0000 (12:54 +0000)]
Put the TigerVNC marker at the end instead of the beginning of the window
title, making it easier to differentiate windows. At the same time remove
the translation tags as there is nothing in there that should be translated.
Peter Åstrand [Mon, 29 Aug 2011 13:14:51 +0000 (13:14 +0000)]
Avoid translation strings with leading and/or trailing whitespace. Our
experience is that translators very often fails to notice them and
forgets to include the whitespace in the translated string.
DRC [Tue, 23 Aug 2011 23:44:22 +0000 (23:44 +0000)]
We can't assume that Pixman is under ${includedir}, because ${includedir} depends on the install prefix. Fortunately, XSERVERLIBS_CFLAGS should contain the correct include directory for Pixman, so we can use this variable directly or parse it for the include directory.
DRC [Tue, 23 Aug 2011 20:26:11 +0000 (20:26 +0000)]
Clarify when in-tree version of Zlib is being used, and remove redundant "not found" message for the system version (find_package() already takes care of that.)
Peter Åstrand [Tue, 23 Aug 2011 12:04:46 +0000 (12:04 +0000)]
Make sure to include config.h in every compilation unit. Otherwise,
the necessary defines will only be visible as a side effect of
including other headers, leading to problems with things like
translations, which will fail in various places.
DRC [Fri, 19 Aug 2011 04:57:18 +0000 (04:57 +0000)]
Add support for TurboVNC pseudo-encodings and Grayscale JPEG compression so that, when a TurboVNC viewer is connected, the TigerVNC Server will behave exactly like the TurboVNC Server.
Brian Hinz [Thu, 18 Aug 2011 01:09:19 +0000 (01:09 +0000)]
add support for "hidden" compression levels 0,7,8,9 in the gui (JComboBox is now editable). Also addded some sanity checks to make sure only 0-9 can be passed in via the gui or the command line.
DRC [Wed, 17 Aug 2011 02:30:34 +0000 (02:30 +0000)]
Implement recommendations from low-level performance study (undocument compress levels 7-9 in the GUI, since they do nothing but increase CPU usage, set the default compress level to 1, and include a note that levels higher than 3 are rarely useful)
DRC [Wed, 17 Aug 2011 02:27:59 +0000 (02:27 +0000)]
Further optimizations to the Tight encoder to eliminate getImage() overhead. The encoder now directly accesses the framebuffer for solid rectangle computation, JPEG encoding, and color counting (if pixel translation is not required.) Also moved everything in tightEncode.h into the TightEncoder class to eliminate all of the static mess (this will be important later on if we decide to multi-thread the encoder.)
DRC [Thu, 11 Aug 2011 11:18:34 +0000 (11:18 +0000)]
Ported encoding optimizations from TurboVNC. The changes to the Tight parameters were determined through extensive low-level profiling (see http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf). The other enhancements involved: (1) porting the solid subrectangle pre-computation code from TightVNC/TurboVNC (it makes a pretty big difference-- see report), (2) encapsulating the JPEG encoder in its own class (this eliminates a buffer copy, and the JPEG buffer is now set to a decent size where it shouldn't ever need to be paged or re-allocated, except in rare corner cases), (3) adding support for last rect. encoding (necessary to support the solid rectangle pre-computation enhancements.
Peter Åstrand [Thu, 11 Aug 2011 09:14:54 +0000 (09:14 +0000)]
Update the fl_update_clipboard function, so that it matches the latest
version of the win32 clipboard patch available from
http://www.fltk.org/str.php?L2636. See bug 3386240.
DRC [Tue, 9 Aug 2011 11:12:55 +0000 (11:12 +0000)]
Revert r4498 and fix #3305357 properly. The issue was two-fold: (1) the compress buffer allocated by the Tight encoder was not large enough, and (2) Zlib 1.2.5 can sometimes call deflate(..., Z_BLOCK) within the body of deflateParams(), so we need to check avail_in after calling checkCompressionLevel() to ensure that there is still data left to compress before we call deflate() again.
DRC [Tue, 9 Aug 2011 02:26:30 +0000 (02:26 +0000)]
(Re-)fix static Xvnc build. We can leverage the BUILD_STATIC option to modify our fake libtool scripts such that they pick up the static libstdc++.a. Unfortunately, adding -static-libgcc to those scripts makes libtool barf, so we still have to add that flag to LDFLAGS in build-xorg.
DRC [Mon, 1 Aug 2011 20:25:40 +0000 (20:25 +0000)]
Only try to run the libjpeg-turbo test program if we aren't cross-compiling. In a cross-compile environment, we'll settle for just making sure it compiles and links. Even though that can theoretically produce situations in which the wrong libjpeg is linked, such situations would be exceedingly rare in a cross-compile environment, since there is no "system libjpeg" to accidentally link with.