Java viewer to slow to connect about turbovnc HOT 6 CLOSED

Which version of the viewer?

from turbovnc.

2.0.80 (20151217), using Java 8u72 on Windows 7.

from turbovnc.

OK, I'll investigate further. I see a delay on Windows using Java as well, but not nearly as long a delay as what you're seeing.

from turbovnc.

So with the Java Viewer debugging turned on I see this:

DesktopWindow: GraphicsDevice does not support HW acceleration.
PlatformPixelBuffer: Native pixel format is depth 24 (32bpp) little-endian rgb888
PlatformPixelBuffer: Native pixel format is depth 24 (32bpp) little-endian rgb888
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
CConn: Requesting Tight encoding
CConn: Screen 0 work area: 0, 0 1920 x 1152
CConn: Screen 1 work area: 1920, 0 1920 x 1200
CConn: Spanned work area: 0, 0 1920 x 1152
Viewport: Set geometry to 331, 92 1258 x 967
CMsgReaderV3: Server supports GII version 1
CConn: Enabling GII
CConn: Enabling continuous updates

It takes 7 seconds until "CConn: Screen 0 work area: 0, 0 1920 x 1152" and then another 7 seconds until "CConn: Screen 1 work area: 1920, 0 1920 x 1200" shows up. I have 2 monitors, perhaps that's why my delay is longer?

from turbovnc.

I unplugged my 2nd monitor and it did indeed cut the delay from 14 to 7 seconds.

from turbovnc.

You're running into this issue:

https://bugs.openjdk.java.net/browse/JDK-6477756

Workaround is to set the Java system property sun.awt.nopixfmt to true. I just checked in a commit to master and 2.0.x that should make this happen automatically. As far as I can tell, there are no ill effects from doing this. Basically, setting sun.awt.nopixfmt=true tells Java 2D to use the default pixel format instead of probing for all available pixel formats, but I think that's probably fine, because the Java TurboVNC Viewer always tries to use the Windows GDI Java 2D blitter. As far as I understand, probing for pixel formats is only necessary when using the OpenGL or DDraw Java 2D blitters, but I included a safety net in case something goes wrong (the old behavior can be reverted by explicitly setting sun.awt.nopixfmt to 0 or false.)

from turbovnc.