On some browsers, a Java applet runs in the same thread as the browser itself. A CPU intensive applet will thus slow down the browser, giving delayed responses to user input in other parts of the program. The solution to this problem, is to let the main part of the applet run in a separate thread. The separate thread scenario is common enough that a special interface, called Runnable, is defined. Classes implementing this interface, must define a run-method that is called automatically when the thread is started.
To be able to support various kinds of image handling, Java defines the two interfaces ImageProducer and ImageConsumer. Classes implementing ImageProducer may generate images from different kinds of sources, and send them to classes implementing ImageConsumer for handling. The applet described in this chapter builds the image in an internal memory buffer as blocks are received from the network. The Java class MemoryImageSource, implementing an ImageProducer, is used to encapsulate the buffer in an ImageProducer, to be able to create a Java Image from it using the createImage-function. The Image representation is needed when ordering Java to draw the image in a window. Note that createImage copies the buffer, so a new image must be created each time the internal buffer is changed.
Java supports various image color models by using subclasses of ColorModel. In our case, where only 16 levels of gray are needed, and indexed color model serves our needs. Java defines the class IndexColorModel, giving up to 256 simultaneous colors by using one byte pixel values for indexing. When initiating an instance of IndexColorModel, one has to specify the red, green and blue color component of each indexed color, along with an alpha value providing transparency. Our applet initiates the first 16 pixel values to represents shades of gray from black (pixel value 0) to white (pixel value 15). Once the IndexColorModel is set up and tied to the MemoryImageSource, the Java library silently handles all color mapping details behind the scene.
Figure 6.2: Conceptual representation of the interworking
of image related classes in the video applet.
Figure 6.2 shows the connections between image handling classes in the applet. Instance names refers to the variable names used in the implementation. The pixelBuff array is the internal pixel buffer, in which updates to the image is made. Calls to createImage combines the values in the pixel buffer with the color values in the color model lookup table, creating a fully colored (or rather grayscaled for our purpose) representation of the image. Passing the image to the drawImage method of the Graphics context, results in the image being drawn on the screen.
Networking is done using BSD sockets [1] encapsulated in classes in the package (class collection) java.net. Every method working on sockets throw exceptions on error, so networking code must be embedded in try-catch-blocks to compile cleanly, even if handling some of the errors is not critical.
In this implementation, reading from and writing to a TCP connection is handled by the Java classes InputStream and OutputStream respectively, both instantiated inside the Socket class.
A separate Java class, DatagramSocket, is used for sockets referencing UDP ``connections''. This class provides the method receive, which is used to read a datagram into an instance of the Java class DatagramPacket. When creating instances of DatagramPacket classes, one has to provide a byte array to be used as a buffer, the size of which sets the maximum packet size to receive. When a package is received from the network, JDK shrinks the size of the buffer to match the packet read. This shrinking makes it impossible to reuse the DatagramPacket -- a new one must be created with the correct buffer size.