Top 10 in 2008
5 popular archives:
All selections are based on page views.
JW hot topic: Tech careers in a slump
Seems like new layoffs are announced every week, projects are dying and software developers are feeling the IT budget squeeze.
Being nervous isn't a crime, but you're better off with information, advice, and a plan.
From the IDG News Network:
Graphics, many programmers still find that they need more flexibility; simply loading and displaying images within an applet or application
often doesn't make the grade. In these cases, the only solution is to create images on the fly. Such a task is made possible
by Java's powerful image-handling framework and the two interfaces that make it up.Before we get too deep into our latest image endeavor, let's review what we learned about images in the preceeding How-To Java column.
Recall that delay is an inherent property of the network-based environment in which Java applets and many Java applications live. Because Java applets and many Java applications depend heavily on resources (classes and media) that are initially available only remotely, the designers of the Java class library had to address the delay posed by network transactions. The result of their efforts was a system in which images are fetched asynchronously, possibly in another thread.
The most visible player in the image game is the Image class. An instance of the Image class represents an image, but it does not need to contain the data that makes up the image -- the Image class provides methods for obtaining information about the image represented by an instance of the class. Due to network
delay, information about an image might not be immediately available. Therefore, each method requires, as a parameter, an
instance of a class that implements the ImageObserver interface.
Whew! That's a whole lot of information crammed into a very small space. If you find that you're scratching your head wondering what this is all about, check out last month's column, for more information.
The developers of the Java class library used the producer/consumer model as the basis for the library's low-level image-handling API. This model, which has several advantages we'll examine in a minute, consists of two tightly coupled components: producers and consumers. You may have been able to guess the components' names, but understanding what they do requires some explanation. Let's take a look.
Image producers are objects that produce image data. An image producer may generate image data itself, or it may provide access
to image data in a particular image format (GIF, JPEG). All image producers implement the ImageProducer interface. Image consumers, on the other hand, are objects that consume image data. Once the image data is consumed, the
object is then free to use (or modify) it. All image consumers implement the ImageConsumer interface.
As I mentioned a moment ago, the producer/consumer model has several advantages: it's modular, which means that existing producers and consumers can be used interchangeably, and new producers and consumers fit seamlessly into the existing framework; and it lends itself to asynchronous interaction, which means that once a connection between a producer and a consumer is made, the producer notifies the consumer only when more information is available. Meanwhile, the applet or application is free to do other work.
Image APIImageProducer APIImageConsumer APIImageObserver API