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

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

In a drawing scene of the top-level heavyweight container component of Swing, you can see that paint drawing is triggered after the underlying event is reached via awt-windows eventloop; however, for lightweight Swing components, the paint is triggered by a call to repaint in java code, which will send to RepaintManager.addDirtyRegion and scheduleProcessingRunnable at the same time. These are two different ways to trigger drawing throughout the GUI lifecycle, but the processing after the trigger is handed over to RepaintManager.

In retrospect, when JFrame is constructed, root pane, layered pane,content pane, glass pane, etc., will be created. These lightweight Swing components without peers will be repaint when constructed. Although these Swing components are required to draw before the windows peer window is created, RepaintManager is able to coordinate this pace (specifically, to judge the situation when a repaint request is received, as in this case, the request will not be recorded in the redraw area because the top-level container has not yet been drawn). So the end result is that only an empty window can be seen in peer.pshow, and then these sub-components will be drawn through paint callback when the underlying message arrives, and then the hello world will be displayed. If the eyes are good, you can see that there is a "flicker".

This is the simplest analysis of the basic operating mechanism of Swing applications, which will be analyzed in more detail below.

The GUI of Swing is always built by a combination of top-level container components and lightweight Swing components. The main difference between top-level containers and other components is that top-level containers do not have their own paint logic. All top-level containers paint by using the underlying system API to draw peers. There is no paint logic implementation of java2d, and the top-level containers are like what the peers are drawn. It can only control some of the matching display properties of the peers. So the effect is, for example, to draw a jframe on the windows platform and display an item on the taskbar in addition to a window on the desktop. All four top-level containers of Swing getToolkit () .createPeer (this) (Frame/Dialog/Window) at addNotify, while addNotify is not called at construction time, but at pack/show or setvisible (the three so-called realized materialization methods). After the peer peer is created, it needs to be called through peer.pShow (show/setVisible (true) call) before the underlying system is required to display (so only pack will not display the window). The underlying message queue is notified after the window is displayed, and then it can also be notified from the underlying message after system operations such as the window being minimized or obscured. At this time, the monitoring process will selectively notify the RepaintManager of a redraw request for window content-sub-component redrawing.

The lightweight Swing component delegates the responsibility of drawing to the ui member object, and the ui object is drawn using JAVA2D API. That's what the paint looks like. Specifically, updateUI {setUI (UIManger.getUI (this))} is required when constructing. UIManger will get the ui member class and create an instance according to the current Lobf selection and this.uiClassID, and the subsequent paint callback will be pushed to the ui member class paint, which can be regarded as a policy mode. In addition to saving the ui in the process of Setui, repaint is used to notify RepaintManager for paint callback to complete the component drawing. Lightweight Swing components will also create peers getToolkit (). CreatePeer (this) (LightWeightPeer) when addNotify, but the implementation of this peer (NullComponentPeer) is an empty shell, just as a tag for a lightweight component. In the future, many event handling will have to determine whether the peer is instance of LightWeightPeer so that it can be handled differently. The same Addnotify is not called at construction time, but when it is added to the container.

Note: the constructor itself is the state of the state mode, so the constructor of the GUI component should strive to complete its own drawing to match its status. Lightweight components tell repaintmanager to draw themselves in the constructor in this sense, but the top-level container delays the real drawing intention createPeer to the realization method. This is because the first logical expression logic is to have the container first, and then add the subcomponents to the container, so the top-level container is always constructed first, and then the lightweight subcomponents are added layer by layer. If the topmost container is materialized during construction, it is required that subsequent construction should be done in EDT, and that each addsubcomponent will result in revalidate However, if you delay the drawing separation of the top-level container to the realization method, you can express the concept that the container is filled with sub-components to be displayed and then present the concept one by one, similar to a complete load of a web page, and then note that if you want to operate the components in EDT after the implementation of the current method, and the top-level container provides a unique pack method. It is used to rearrange the verification size and location of all sub-components at once, and then show after pack, which is the most efficient one-time calculation.

This is how top-level containers and lightweight components are born and drawn. In the following life cycle, GUI will be completed on demand according to the event listening mechanism, whether it is a system event or because repaint calls an active post event, and then execute the paint drawing in the listener in EDT after the event arrives. The top-level containers and lightweight components already provided by Swing have registered their own paint snooping because of their respective definitions, and developers can maintain or develop new components according to this pattern to meet the needs of the application. For example, jbutton has mousepress listener by default. After the arrival of the mousepress event, the mouse color deepening is set in the listening response to indicate pressing, and then repaint is called to ask for redrawing, and then the paint callback of jbutton is executed in EDT. At this time, it is drawn in dark color, and a pressed effect comes out.

The following is a specific analysis of the handling of various events.

For the top-level container triggered by the underlying event message, when the notification is that the expose exposes the hidden area (exposing the hidden part or restoring the minimum or * drawing, etc.), the processing process will involve double-cache processing, that is, if possible, the old image information in the cache will be directly used to overwrite without redrawing.

The so-called double cache mechanism is to temporarily write a whole piece of display content into a memory space, and then copy the one-time memory into the display area for display. This is because if the display area is written directly, as the display area is gradually written by the writing thread, it may undergo multiple screen refreshes, resulting in the formation of a process image for each refresh, causing a flickering feeling to the human eye. At the same time, a side benefit is that you can do cache standby for each window (not just for a screen double cache). When the occluded part of the window reappears, you can copy the cache directly to overwrite it, eliminating the need to perform painting logic, thus improving efficiency.

The current OS generally supports double caching mechanism. If the underlying system supports double caching per window, the expose message will be processed locally without notification for sub-component drawing. If the underlying system does not support it, the message will be sent to the wcomponetpeer.handleexpose for callback processing. In this case, a parameter-controlled dual-cache mechanism can be provided under the Swing mechanism. The parameter control here needs to start with the construction process of RepaintManager.

First of all, RepaintManager can be globally specified through static setCurrentManager (SomeCurrentManager). By default, you use currentRepaintManager () {new RepaintManager (BUFFER_STRATEGY_TYPE)} to get a delayed creation singleton. RepaintManager has a static class initialization process that involves double cache settings:

Static {

NativeDoubleBuffering= "true" .equals (AccessController.doPrivileged (

NewGetPropertyAction ("awt.nativeDoubleBuffering")); / / start parameter control of JVM. Default is false.

Stringbs=AccessController.doPrivileged (

NewGetPropertyAction ("swing.bufferPerWindow"); / / whether it is cached per window.

If (headless) {

BUFFER_STRATEGY_TYPE=BUFFER_STRATEGY_SPECIFIED_OFF

}

Elseif (bs==null) {

BUFFER_STRATEGY_TYPE=BUFFER_STRATEGY_NOT_SPECIFIED

}

Elseif ("true" .equals (bs)) {

BUFFER_STRATEGY_TYPE=BUFFER_STRATEGY_SPECIFIED_ON

}

Else {

BUFFER_STRATEGY_TYPE=BUFFER_STRATEGY_SPECIFIED_OFF

}

}

PrivateRepaintManager (shortbufferStrategyType) {

/ / Ifnativedoublebufferingisbeingused,doNOTuse

/ / Swingdoublebuffering.

"leBufferingEnabledpeople" nativeDoubleBuffering

This.bufferStrategyType=bufferStrategyType

}

PublicvoidsetDoubleBufferingEnabled (booleanaFlag) {

DoubleBufferingEnabled=aFlag

PrivatesynchronizedPaintManagergetPaintManager () {

If (paintManager==null) {

PaintManagerpaintManager=null

If (disabled BufferingEnabledBuffering) {

Switch (bufferStrategyType) {

CaseBUFFER_STRATEGY_NOT_SPECIFIED:

If ((SunToolkit) Toolkit.getDefaultToolkit ()).

Whether to disable vistadwm under useBufferPerWindow () {/ / windows

The bufferPerWindow is determined by the windows system property without declaring the paintmanager.

PaintManager=newBufferStrategyPaintManager ()

}

Break

CaseBUFFER_STRATEGY_SPECIFIED_ON:

PaintManager=newBufferStrategyPaintManager ()

Break

Default:

Break

}

}

/ / nullcasehandledinsetPaintManager

SetPaintManager (paintManager)

}

ReturnpaintManager

}

VoidsetPaintManager (PaintManagerpaintManager) {

If (paintManager==null) {

PaintManager=newPaintManager ()

}

}

The above is all the content of the article "sample Analysis of lightweight Swing components". 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.