![]() |
|||
![]() ![]() |
![]() |
|
![]() |
Debug GraphicsThe JComponent class introduces the concept of debug graphics. When debug graphics are enabled, a component paints itself slowly, allowing the component developer to easily see how the component is painting itself. Debug graphics are enabled or disabled for a component via the setDebugGraphicsOptions method. The current state of these options can be queried with the getDebugGraphicsOptions method. A complete description of using debug graphics and available options is presented in Chapter 25. Double BufferingA serious problem with the AWT is poor painting performance. Many component developers reduced this problem by double buffering their components. When a component is double buffered, it paints to an offscreen buffer and then updates the display in a single operation. Even though this makes the painting of a component slower than painting directly to the screen, it appears better to the user because the display update is done very quickly. The user does not see the raw painting operation, only the result when the display is updated. Double buffering was such a common painting optimization that it was built into the JFC. Having double buffering contained in the toolkit allows for further optimizations to be made. When a component is double buffered, its children are also double buffered using the same buffer. When each component managed its double buffering, multiple offscreen images were createdone for each component. The JFC optimizes the buffer creation to a single buffer for the top-level component. This single buffer is shared by all the components contained in that component. This saves a significant amount of memory. The setDoubleBuffered method is used to enable double buffering for a component that extends JComponent. This method takes a single boolean parameter specifying the state for double buffering. The isDoubleBuffered method can be used to determine if a component is currently double buffered. While these methods are contained in the JComponent class, they rarely need to be called by application code. The content pane of JFC top-level components has double buffering enabled. As will be shown in Chapter 8, Frame Windows, the content pane is the parent in most JFC component hierarchies. Thus, the components added to the content pane are double buffered, even if their setDoubleBuffered method is not explicitly called. Efficiency MethodsCreating unnecessary temporary objects can cause significant performance problems in a Java application. The AWT Component class creates objects and returns them to the caller in its getBounds, getSize, and getLocation methods. In many applications, the object returned from these methods is a temporary object. To avoid the creation of the object, new versions of these methods have been added to the JComponent class. The new version takes an instance of the class that is returned from the method. The parameter object is altered to contain the values from the component, and it is also returned from the method. The old and new techniques for using getBounds are shown next. This will be more efficient if the getBounds method is called for multiple components because the same Rectangle instance can be shared for all the calls. // // Original JDK 1.1 getBounds technique // This caused a Rectangle to be created in // the getBounds method. // Rectangle bounds = component.getBounds(); // // New JDK 1.2 getBounds technique // Rectangle bounds = new Rectangle(); component.getBounds( bounds ); Another common programming technique is to call the getSize method and then use the height and width properties from the returned Rectangle. The JComponent class defines the getWidth methods that return these properties directly without creating a Rectangle instance. Similarly, there are the getX and getY methods to return the x and y coordinates without creating a Point instance, as would be done if the getLocation method were called. An example of the old and new techniques for the getSize method is shown next. // // JDK 1.1 getSize technique. // This caused two Rectangle instances to be created. // int width = component.getSize().width; int height = component.getSize().height; // // New JDK 1.2 technique int width = component.getWidth(); int height = component.getHeight();
SummaryThis chapter has taken a long look at the JComponent class. This class serves as the root of the visual component hierarchy contained in the JFC. As such, it has become a dumping ground for functionality required by all the visual components. You looked at how client properties are an efficient place to store data that may or may not be present for a given component. You saw that all JComponent instances may contain a ToolTip and a border. You saw how a single method call is all it takes to enable double buffering for a component. The JComponent class contains methods for handling keystrokes and automatic scrolling. Using the family of focus methods contained in the JComponent class, hints can be given to the focus manager for how focus transversal should occur. A component can also be specified to not be able to acquire the input focus programmatically or not at all. You were also introduced to the look-and-feel support contained in the JComponent class. This support is the foundation of the pluggable look-and-feel architecture contained in the JFC. As much material as this chapter covered about the JComponent class, it is not complete. There is more functionality that is used primarily by subclasses. This additional functionality is presented in Part V of this book.
|
![]() |
|