[FreeNX-kNX] vnc session does not work

Gian Filippo Pinzari pinzari at nomachine.com
Tue Oct 19 15:08:37 UTC 2004


Doug Burks wrote:
> Perhaps the FreeNX community could build our own nxviewer that
> included support for TightVNC, RealVNC, UltraVNC, and the other
> flavors that are out there.

Probably nxviewer doesn't get all the attention it deserves from
NoMachine, but that's just because we don't have the resources
to develop all the agents at the same level.

> I, personally, would like to see an
> nxviewer that could auto-scale the VNC session for times when you're
> on a machine with a resolution of 800x600 and you're connecting to a
> VNC server with a resolution of 1024x768 (see UltraVNC viewer for
> example).

Me too.

>>are there any performance gains using the tight-stuff compared to the
>>"Use X plain bitmaps" (using the nxclient of course)?

NX agents work in a way that the original RFB or RDP packets are
transmitted to the local proxy unmodified, so that the agent doesn't
have to re-encode them on the server. The packets are still subject
to all the NX encoding techniques, including caching. Actually the
RFB packet (Tight, Hextile, etc.) is just another "pack method" of
the PutPackedImage message. High-level X protocol messages are sent
(and compressed) whenever the original viewer sent plain X protocol,
so, depending on how cacheable are the RFB packets and how much addi-
tional X traffic is used by the viewer, the compression can be signi-
ficant. In the worst case, compression is slightly better than with
the original viewer (due to the residual compression of the X protocol)
but with no performance penalty (as the packet is only uncompressed
on the local client).

Setting the encoding to plain bitmaps, NX has to decode the bitmap
on the agent/viewer and then compress it again. This is going to waste
CPU cycles compared to handling the RFB packets in their original
format, so the best option is to fix nxviewer to handle the missing
encodings.

/Gian Filippo.





More information about the FreeNX-kNX mailing list