Shulou(Shulou.com)06/02 Report--

Editor to share with you AWT and Swing painting example analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

AWT and Swing painting

In AWT, for heavyweight components, when drawing, follow the call as follows:

1) redraw because the system triggers: (to put it bluntly, it means that this redrawing is not artificial, not because we write our own code to call functions such as repaint () to redraw, but because the system feels it is necessary to redraw. )

The ◆ "AWT" determines whether the part or the whole part needs to be painted.

The ◆ "AWT" causes the event dispatcher thread to call the widget's paint () method.

2) redraw because the program triggers: (the operation of artificially forcing redrawing in the message response function or elsewhere)

The ◆ "program" determines whether some or all of the parts need to be redrawn to correspond to changes in the internal state.

The ◆ "program" calls the widget's repaint (), which registers an asynchronous request with "AWT"-- the current widget needs to be redrawn.

The ◆ "AWT" causes the event dispatcher thread to call the widget's update () method.

◆ if the widget does not override the (override) update () method, the default implementation of update () clears the widget background (if the widget is not "lightweight") and then simply calls the paint () method.

Description: no matter which way to trigger redrawing, it can be attributed to the paint () function, so why is there an intermediate step "update ()" for the program trigger mode? This is so that we can rewrite the update () method and exercise the control we want in it, that is, we can do some articles here. Of course, we can also override the paint () function, but with the update () function, we can not interfere with paint (), let it "fully" responsible for drawing, and in update () this place to exercise the control we need. For example, the "incremental drawing" that can only use heavyweight components is first triggered by the system to draw paint, and then on this basis (that is, under the background), repaint is called in the message response function of the left mouse button, and then the update function is rewritten, only letting the update function draw the newly added content, instead of calling the paint function inside the update function, thus avoiding the paint function. That is, the so-called "incremental drawing" is realized. However, it should be noted that incremental rendering is only useful for some special GUI parts, such as the Canvas class we used in the example we gave below (that is, the example we just used to describe "incremental drawing"), which inherits directly from the Component class, but not from the Container class, because we have implemented our own paint method in the Container class and have a new mechanism. This is inconsistent with the large set of paint methods based on the Component class we mentioned above.

For lightweight components, they all inherit from the Container class, and "lightweight" components require a "heavyweight" component on the container architecture to provide a place for painting. When this "heavyweight" ancestor is told to draw its own form, it must turn the request for painting into a request for painting for all its descendants. This is handled by the paint () method of java.awt.Container, which calls the paint () method that contains all visible lightweight parts that intersect with the drawing area. Therefore, for all Container subclasses that override the paint () method ("lightweight" or "heavyweight", the subclass of Container is not necessarily a lightweight component, hehe), you need to call the parent class's paint method, that is, super.paint (g), at the end of the function.

Finally, for AWT drawing, the following guidelines are given:

◆ for most programs, all client area drawing code should be placed in the widget's paint () method.

By calling the repaint () method, the ◆ program can trigger a future paint () call instead of calling the paint () method directly.

◆ for parts with a complex interface, you should trigger the repaint () method with parameters to define the area that actually needs to be updated; calling without parameters will cause the entire part to be redrawn.

◆ because the call to repaint () first results in a call to update (), which by default causes a call to paint (), so heavy-level parts should override the update () method to achieve incremental drawing, if necessary (lightweight parts do not support incremental drawing).

The java.awt.Container subclass that ◆ overrides the paint () method should call super.paint () in the paint () method to ensure that the subassembly can be drawn.

The complex parts of the ◆ interface should flexibly use the clipping area to narrow the scope of the painting to include only those that intersect with the clipping area.

The process of Swing painting

Swing handles "repaint" requests in a slightly different way than AWT, although it is essentially the same for application developers-- it also triggers paint (). Swing does this to support its RepaintManager API (described later), just as it does to improve painting performance. Painting in Swing can go two ways, as follows:

(a) the need for painting first arises from a heavyweight ancestor (usually JFrame, JDialog, JWindow or JApplet):

one. The event dispatcher thread calls its ancestor's paint ()

two. The default implementation of Container.paint () recursively calls the paint () method of any lightweight descendant.

three. When the first Swing part is reached, the default execution of JComponent.paint () does the following steps:

◆ if the double buffering property of the widget is true and the double buffering on the widget's RepaintManager has been activated, the Graphics object will be converted to an appropriate off-screen Graphics.

◆ calls paintComponent () (pass in the off-screen Graphics if double buffering is used).

◆ calls paintBorder () (pass in the off-screen Graphics if double buffering is used).

◆ calls paintChildren () (passing in off-screen Graphics if double buffering is used), which uses attributes such as cropping and shading and optimizedDrawingEnabled to closely determine which descendants' paint () to call recursively.

◆ if the double buffering property of the widget is true and the double buffering on the RepaintManager of the widget has been activated, copy the off-screen image to the widget using the original screen Graphics object.

Note: steps # 1 and # 5 of JComponent.paint () are ignored in recursive calls to paint () (here JComponent refers to the components that need to be called recursively in the paintChildren () function, as described in step # 4), because all lightweight parts in the swing form hierarchy will share the same off-screen image for double buffering.

(B) the drawing requirement arises from the repaint () call of a javax.swing.JCponent extension class:

one. JComponent.repaint () registers an asynchronous redrawing requirement for the widget's RepaintManager, which uses invokeLater () to queue an Runnable into the event queue for later execution of the requirement on the event dispatch thread.

two. The Runnable executes on the event dispatch thread and causes the RepaintManager of the part to call paintImmediately () on the part, which performs the following steps:

◆ uses the crop box and the shading and optimizedDrawingEnabled properties to determine the "root" widget, and painting must start with this widget (dealing with transparent and potentially overlapping parts).

◆ if the double buffering property of the root part is true, and the double buffering on the RepaintManager of the root part is activated, the Graphics object is converted to the appropriate off-screen Graphics.

◆ calls paint () on the root part (which performs steps # 2-4 of JComponent.paint () in (A) above), causing all parts under the root assembly that intersect the crop box to be drawn.

◆ if the doubleBuffered property of the root part is true and the double buffering on the RepaintManager of the root part has been activated, copy the off-screen image to the part using the original Graphics.

Note: if there are multiple repaint () calls to the widget or any of its ancestors before the redrawing is completed, all of these calls will be folded to a single call, that is, the paintImmediately () of the SWing part that goes back to the top (the layer here refers to that kind of Hierarchy, not the top figure or button shown to us) and calls its repaint (). For example, if a JTabbedPane contains a JTable and two calls to repaint () are issued before the existing redrawing requirements in its containment hierarchy are completed, the result will be a single call to the paintImmediately () method of the JTabbedPane part, triggering the execution of paint () for both parts.

This means that update () is no longer called for Swing parts.

Although the repaint () method results in a call to paintImmediately (), it does not consider "callback" drawing, and the client-side drawing code is not placed in the paintImmediately () method. In fact, unless there is a special reason, there is no need to overload the paintImmediately () method at all.

Swing painting guidelines

Swing developers should understand the following guidelines when writing drawing code:

one. For Swing parts, whether system-triggered or program-triggered requests, the paint () method is always called; update () is no longer called by the Swing part.

two. A program can trigger an asynchronous paint () call through repaint (), but it cannot call paint () directly.

three. For complex interfaces, you should call repaint () with parameters so that you can only update the areas defined by that parameter; instead of calling repaint () with no parameters, causing the entire widget to be redrawn.

four. The three elements of implementing paint () in Swing are calling three separate callback methods:

◆ paintComponent ()

◆ paintBorder ()

◆ paintChildren ()

A subclass of the Swing part, if you want to execute your own drawing code, should put your own drawing code within the scope of the paintComponent () method. Don't put it in paint ().

five. Swing introduces two attributes to maximize the performance of painting:

◆ opaque: does the widget want to redraw all the pixels in the range it occupies?

◆ optimizedDrawingEnabled: are there any descendants of this part to overlap with it?

six. If the (shading) opaque property of the Swing part is set to true, it means that it is responsible for drawing all pixel bits in the range it occupies (including clearing its own background in paintComponent ()), otherwise it will cause screen junk.

seven. If the opaque and optimizedDrawingEnabled properties of a widget are set to false, it will cause more processing to be performed in each painting operation, so it is advisable to use transparent and overlapping widgets at the same time.

eight. A typical practice for extension classes of Swing parts that use UI proxies (including JPanel) is to call super.paintComponent () in their own implementation of paintComponent (). Because the UI agent can be responsible for clearing the background of a shading component, but this operation needs to be determined according to the setting in Rule # 5.

nine. Swing supports built-in double buffering through the doubleBuffered property of JComponent, which defaults to true for all Swing parts. However, setting the shading of the Swing container to true has an overall idea of turning on the properties of all lightweight descendants on the container, regardless of their respective settings.

ten. It is strongly recommended that you use double buffering for all Swing parts.

eleven. Components with complex interfaces should flexibly use the cut box to draw only those areas that intersect the cut box, so as to reduce the workload.

The above is all the content of this article "sample Analysis of AWT and Swing painting". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.