http://sourceforge.net/projects/turbovnc/files/1.2.3/
Significant changes relative to 1.2.2:
[1]
Fixed an issue whereby the Java TurboVNC Viewer would not enable the OS
X Lion full-screen mode feature on OS X 10.10 "Yosemite".
[2]
Fixed a regression introduced in 1.2.2 that caused a non-fatal
NullPointerException in the Java TurboVNC Viewer whenever the scaling
factor was changed in the options dialog.
[3]
Fixed an issue in the Java TurboVNC Viewer whereby the toolbar would
sometimes appear all black or be overwritten by the initial framebuffer
update when running under Java 1.7 and later.
[4]
Fixed an issue whereby the Java TurboVNC Viewer would unnecessarily add
scrollbars to the viewer window if the remote desktop was exactly large
enough to fit in the window without using scrollbars.
[5]
Fixed an issue whereby the /grabkeyboard, /scale, and /span command-line
parameters to the Windows TurboVNC Viewer could not be specified in
uppercase.
[6]
The Windows TurboVNC Viewer now supports scaling factors > 200.
[7]
Java 1.7 and later on Mac platforms no longer include a
hardware-accelerated 2D blitter for Java 2D, opting instead to use only
OpenGL for image drawing. When using the default pixel format (BGRX),
this is incredibly slow on some Macs, because the OpenGL blitter is
having to set all of the alpha values to 255 (opaque.) Thus, the Java
TurboVNC Viewer will now automatically use an alpha-enabled pixel format
(BGRA) for its back buffer if it detects that it is running on a Mac
with Java 1.7 or later (which will generally be the case when the viewer
is deployed as an applet or using Java Web Start.) This improves
drawing performance by as much as 4-5x on certain Mac models, although
the drawing performance with Apple Java 1.6 is still going to be faster
than with Java 1.7 or later. The Java TurboVNC Viewer will also now
automatically use an alpha-enabled pixel format on non-Mac platforms if
it detects that OpenGL Java 2D blitting is being selected (normally
accomplished by setting the "sun.java2d.opengl" system property to "true".)
The "turbovnc.forcealpha" Java system property can be used to override
the default behavior described above (refer to User's Guide.)
[8]
Normally, Java 2D uses Direct3D by default for blitting (image drawing)
on Windows platforms, but GDI blitting is almost always faster
(sometimes much faster.) Thus, the Java TurboVNC Viewer now attempts to
disable Direct3D blitting on Windows unless it is specifically requested
(which can be accomplished by setting the "sun.java2d.d3d" system
property to "true".) Because Direct3D blitting can't be disabled
programmatically under Java 1.6 and earlier, the vncviewer-java.bat
script and the Windows start menu shortcut now pass
-Dsun.java2d.d3d=false to java to ensure that Direct3D blitting is
always disabled when the Java TurboVNC Viewer is run as a standalone
application.
[9]
Improved the Tight decoding performance in the Windows TurboVNC Viewer
by 5-15%.
[10]
Since the Java TurboVNC Viewer already has its own double buffering
mechanism, it now disables double buffering in Java 2D. The primary
advantage of this is that MIT-SHM pixmap support is no longer required
on Un*x platforms in order to achieve optimal performance. This also
makes the viewer faster on some systems. On Windows, the Java viewer is
now as fast as or faster than the native viewer as a result of this
change and [8]. You can set the turbovnc.swingdb system property to
true to restore the old behavior.
[11]
Fixed multiple issues in the Java TurboVNC Viewer related to full-screen
mode and desktop resizing and the interaction thereof.
-- When in full-screen mode, the viewer would sometimes abort with
"Destination buffer is not large enough" if the remote desktop size was
increased.
-- When in full-screen mode, the viewer would sometimes exit full-screen
mode without re-entering it if the remote desktop size was changed.
This was particularly known to be a problem when using full-screen mode
on OS X 10.7 or later.
-- Fixed a couple of other timing-related issues (race conditions) that
could sometimes occur when resizing the window or entering/exiting
full-screen mode. These issues would cause non-fatal exceptions or other
unexpected behavior.
-- When resizing the window to the default size, the viewer would
sometimes leave a border around the remote desktop if the remote desktop
size was less than the local desktop size.
-- The viewer window will now be automatically resized to the default
size/position whenever the span mode is changed.
[12]
The Java TurboVNC Viewer will no longer attempt to send a desktop resize
message to servers that don't support it. This fixes a "Broken pipe"
error that occurred when the -desktopsize parameter was used when
connecting to the TurboVNC 1.2.x Server (or earlier versions.)
[13]
Fixed multiple issues in the Windows TurboVNC Viewer related to
full-screen mode, desktop resizing, spanning, scaling, and the
interaction thereof.
-- When in full-screen mode, resizing the remote desktop sometimes
produced unexpected results, such as residual images of the old remote
desktop appearing around the borders of the new desktop.
-- The calculations for automatic spanning now take into account whether
scaling is enabled. Previously, the decision as to whether to span the
window across one screen or multiple screens was based on the unscaled
remote desktop size.
-- When scaling is enabled, the default window position/size is now
computed correctly. Previously, it was computed based on the unscaled
remote desktop size.
-- The viewer window will now be automatically resized to the default
size/position whenever the span mode or scaling factor is changed, or
whenever the remote desktop size changes.
[14]
On Un*x/X11 platforms, the Java TurboVNC Viewer will now send and set
the PRIMARY clipboard selection by default (thus enabling middle mouse
button copy/paste between the server and the client.) This can be
disabled by setting the "turbovnc.primary" system property to false.
[15]
The Java TurboVNC Viewer can now optionally use an external SSH client
when the "ExtSSH" parameter is set to 1. The full SSH command line can
also be specified using the VNC_VIA_CMD and VNC_TUNNEL_CMD environment
variables, as with the native viewers. See the TurboVNC User's Guide
for more details.
[16]
All JAR files in the official TurboVNC packages for Linux are signed
using an official code signing certificate, to comply with applet/JWS
security requirements in Java 7u51 and later.
[17]
The vncviewer-java.bat and vncviewer-javaw.bat scripts, which are used
to launch the Java TurboVNC Viewer on Windows systems, did not work
unless the current directory was the TurboVNC install directory. This
has been fixed.
[18]
Sending Alt+{letter} key sequences to the server (for instance, to pop
up one of the menus in an application) did not work properly when using
the Java TurboVNC Viewer. This has been fixed.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users
