VNCj

How to serve VNC from Java using VNCj

VNCj allows six different models of serving VNC to suit your particular needs. For most new projects, you will probably use the Swing model (I) while for some you may use the AWT model (II) for code compatibility with AWT. The console model (V) even allows simple console applications to be accessible via VNC.

I. Swing Model

This is the easiest and most powerful way to create a new VNC server from scratch. Your application must inherit the class VNCJFrame, which behaves like a remote JFrame that cannot resize. Of course, you can add a JDesktopPane to it and use many JInternalFrame instances that are resizable.

This model uses the default AWT toolkit for your operating system, which means that it will support the fonts and colors installed, and also the enabled Swing look & feels.

This is basically the lightweight model, with the added efficiency of Swing's RepaintManager which allows us to support incremental frame updates. A separate incremental queue is maintained for each client in shared sessions.

Note that certain operations, such as full frame dragging and text area scrolling, fudge the RepaintManager by calling markCompletelyClean(). To make sure we don't miss the update, this model refreshes the fudging component. This means that full frame dragging will cause full screen refreshes. For best performance, call setDragMode(JDesktopFrame.OUTLINE_DRAG_MODE).

II. AWT Model

If you already have a lot of code based on AWT, you do not have to convert it to Swing/JFC. VNCj contains an AWT toolkit that implements all AWT components with Swing/JFC. Because AWT is only emulated with Swing, you cannot directly use all of Swing's features, but this may be exactly what you need. Your application must inherit the class VNCDesktop. Unlike the Swing model, you can create as many Frame instances as required, where each uses a is attached to a virtual desktop.

Underneath, the AWT model uses the Swing model. The VNCDesktop contains a VNCJFrame with a JDesktopPane, AWT frames are emulated by JInternalFrame instances, and all other AWT components are emulated by their corresponding Swing components. 

(One small problem: the AWT Frame class is hard-coded to use the default toolkit. You must use the ToolkitFrame class instead, which inherits Frame and simply adds the ability to use a different toolkit. Use all other AWT classes as usual. I am working on wrapping the default toolkit, but am encountering many problems. It seems as if replacement is the only solution. For now, you will have to use ToolkitFrame.)

III. Lightweight Model

If your server does not need the windowing features of Swing and AWT, you can simply use the VNCFrame class, which works like the VNCJFrame class described in the Swing model. You can then add add custom lightweight components to it, like Canvas. The frame has a VNCQueue instance that handles incremental frame updates. A separate queue is maintained for each client in shared sessions.

Another option is to avoid using additional AWT components, and draw directly to the frame using the Graphics class (by calling getGraphics() on the VNCFrame). AWT events will be sent to the frame instance itself.

IV. Pixel Model

You may directly manipulate the underlying pixel data of the VNCFrame, which is simply an array of pixels encoded according the client's preferences. You may get the the pixel data from anywhere: a database, a file, the network, or specialized hardware. All you need to do is pour it in. The frame has a VNCQueue instance that handles incremental frame updates. A separate queue is maintained for each client in shared sessions.

And now for the big secret: all above models use the pixel model internally. Every frame has a fixed-size pixel array into which the lightweight components are rendered. In fact, you may use the pixel model together with other models, although you will somehow need to coordinate your changes with those of Swing..

V. Console Model

This model implements an InputStream and a PrintStream for standard left-to-right, upward scrolling console applications. Simply inherit the VNCConsole class and implement your own main() method. The in and out properties represent the two streams.

The implementation is much faster than, for example, using a Swing JTextArea, as all data is encoded in advance using the RectFont class. It also supports incremental frame updates, maintaining a separate queue for each client in shared sessions. This model uses minimal bandwidth and CPU cycles.

You may ask why on earth anyone would want to access a console application via VNC. After all, there are far better protocols if all you need is to transfer console text. However, text-over-VNC does release you from many configuration problems and terminal emulation incompatibilities. Also, terminal emulation is not always available or configured, while a VNC viewer may be up and running. In such cases, VNCj can be a lifesaver.

VI. RFB Model

You may not need or want even a fixed pixel array. In this case, you can design your own class that implements the RFBServer interface. You can use the Rect.encode method to encode pixel information in any of the supported VNC formats, or generate their content through other means.

This, of course, is the underlying model for the rest of the models. VNCJFrame, VNCFrame, VNCDesktop and VNCConsole all implement the RFBServer interface.

(Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
Tal Liron and VNCj are independent of Sun Microsystems, Inc.)