What is the actual difference between paint(), paintComponent() and paintComponents() in Java Swing?
I tried to understand what explained in Oracle docs but I am not clear.
AWT, override paint().
Swing top-level container (e.g.s are JFrame, JWindow, JDialog, JApplet ..), override paint(). But there are a number of good reasons not to paint in a TLC. A subject for a separate question, perhaps.
The rest of Swing (any component that derives from JComponent), override paintComponent().
Neither override nor explicitly call paintComponents(), leave it to the API to call it when needed.
Be sure to also use #Override notation whenever overriding a method.
Doing so would hint at the problem of trying to override paintComponent(..) in a JFrame (it has no such method), which is quite common to see.
You may be interested in reading Painting in AWT and Swing
A quote:
The rules that apply to AWT's lightweight components also apply to Swing components -- for instance, paint() gets called when it's time to render -- except that Swing further factors the paint() call into three separate methods, which are invoked in the following order:
protected void paintComponent(Graphics g)
protected void paintBorder(Graphics g)
protected void paintChildren(Graphics g)
Swing programs should override paintComponent() instead of overriding paint(). Although the API allows it, there is generally no reason to override paintBorder() or paintComponents() (and if you do, make sure you know what you're doing!). This factoring makes it easier for programs to override only the portion of the painting which they need to extend. For example, this solves the AWT problem mentioned previously where a failure to invoke super.paint() prevented any lightweight children from appearing.
Related
I am reading this article on Painting in AWT and Swing which have following paragraph in section "How lightweights get painted"
It's worth noting that the default implementation of Container.update() does not use recursion to invoke update() or paint() on lightweight descendents. This means that any heavyweight Container subclass that uses update() to do incremental painting must ensure that lightweight descendents are recursively repainted if necessary. Fortunately, few heavyweight container components need incremental painting, so this issue doesn't affect most programs.
Please tell me, in which case do I need to have recursive calls to update() or paint() and why?
You don't need recursive calls to update() or paint().
If you want to paint a component all you do is:
component.repaint();
This will add a paint request to the RepaintManager to paint the component and Swing will make sure that the components child components get painted when the paintChildren(...) method is invoked. See A Closer Look at the Paint Mechanism for more information.
What is the actual difference between paint(), paintComponent() and paintComponents() in Java Swing?
I tried to understand what explained in Oracle docs but I am not clear.
AWT, override paint().
Swing top-level container (e.g.s are JFrame, JWindow, JDialog, JApplet ..), override paint(). But there are a number of good reasons not to paint in a TLC. A subject for a separate question, perhaps.
The rest of Swing (any component that derives from JComponent), override paintComponent().
Neither override nor explicitly call paintComponents(), leave it to the API to call it when needed.
Be sure to also use #Override notation whenever overriding a method.
Doing so would hint at the problem of trying to override paintComponent(..) in a JFrame (it has no such method), which is quite common to see.
You may be interested in reading Painting in AWT and Swing
A quote:
The rules that apply to AWT's lightweight components also apply to Swing components -- for instance, paint() gets called when it's time to render -- except that Swing further factors the paint() call into three separate methods, which are invoked in the following order:
protected void paintComponent(Graphics g)
protected void paintBorder(Graphics g)
protected void paintChildren(Graphics g)
Swing programs should override paintComponent() instead of overriding paint(). Although the API allows it, there is generally no reason to override paintBorder() or paintComponents() (and if you do, make sure you know what you're doing!). This factoring makes it easier for programs to override only the portion of the painting which they need to extend. For example, this solves the AWT problem mentioned previously where a failure to invoke super.paint() prevented any lightweight children from appearing.
The paint method:
Invoked by Swing to draw components. Applications should not invoke paint directly,
but should instead use the repaint method to schedule the component for redrawing.
This method actually delegates the work of painting to three protected methods:
paintComponent, paintBorder, and paintChildren. They're called in the order listed
to ensure that children appear on top of component itself. Generally speaking,
the component and its children should not paint in the insets area allocated to the
border. Subclasses can just override this method, as always. A subclass that just
wants to specialize the UI (look and feel) delegate's paint method should just
override paintComponent.
Parameters:
g the Graphics context in which to paint
public void paint(Graphics g)
I've read many times not to override paint(), but to override paintComponent() instead. As seen above, the documentation also suggests to override paintComponent() if you want to specialize the UI.
So, I wanted to trace through the code to see why this is so.
protected void paintComponent(Graphics g)
{
if (ui != null)
{
Graphics scratchGraphics = (g == null) ? null : g.create();
try
{
ui.update(scratchGraphics, this);
}
finally
{
scratchGraphics.dispose();
}
}
}
There are many methods to trace through, but for conciseness, here's update():
public void update(Graphics g, JComponent c)
{
if (c.isOpaque())
{
g.setColor(c.getBackground());
g.fillRect(0, 0, c.getWidth(),c.getHeight());
}
paint(g, c);
}
An overloaded version of paint() is called, and paint(), itself, calls paintComponent(). So, I guess I'm just trying to figure out what's going on here exactly. I'm very new to Swing; there are a lot of classes and it's pretty difficult to trace through all of them, especially with my limited knowledge of using GUIs, in general.
Are these methods constantly calling each other, thereby giving the illusion of an image on the screen? If so, why does it matter so much if you override paint() instead of paintComponent? I imagine that my logic is in some way flawed or lacking, considering that for applications, the documentation advises against invoking paint() directly, and instead suggests to invoke repaint(). So, basically, I'm just trying to get some insight into the overall relationship between paint(), paintComponent(), repaint(), etc.
Firstly take a look at...
Performing Custom Painting and
Painting in AWT and Swing
The second should be compulsory reading for all Swing developers.
paint is (within the context of this question) the top level method called (update is actually called first, which just forwards to paint) when the RepaintManager wants a component to be painted.
paint is responsible for (amongst other things) calling paintComponent, paintBorder and paintChildren. If you're not careful you could compromise your components ability to paint. So if you HAVE to override paint, make sure you are calling super.paint.
It's important to note, the if a child component is updated, the parent component may not be repainted, so it don't try and use paint to provide overlays for your component.
paintComponent is responsible for painting the "background" of the component. This basically delegates to the look and feel.
In the case of something like JPanel, it will fill the background with the background color (if set to opaque). In the case of something like JTable, it will paint the rows, columns and cell values.
It is very important to ALWAYS call super.paintComponent, especially when dealing with transparent components.
repaint will make a request to the RepaintManager which may consolidate the paint requests so as to reduce the actual number of paint events that are raised. This helps improve performance.
The important thing to note here is that you don't control the paint process, so don't try, work with it instead.
Your paint method is also expected to run quickly, so avoid time consuming operations, like loading resources, or compound loops where possible. If you can, create backing buffers and paint those instead
ps- Paint is fun ;)
I have tried tutorials on this but I still don't quite understand it. Basically my question is which method is better and why? Should I use paint or paintComponent?
Please try to keep the answer simple, thanks.
Quoting from documentation of paint() method
This method actually delegates the work of painting to three protected methods: paintComponent, paintBorder, and paintChildren.
...
A subclass that just wants to specialize the UI (look and feel) delegate's paint method should just override paintComponent.
It looks like the paint() method actually draws the component, including the border and children. If you only want to customize the component's appearance excluding the border and children, you use paintComponent().
http://docs.oracle.com/javase/7/docs/api/javax/swing/JComponent.html#paint(java.awt.Graphics)
Generally speaking, when painting in Swing, it is recommended to override paintComponent.
There are a number of reasons why, one is paintComponent is painted at the bottom layer, meaning you won't accidentally wiping out any components that were rendered during the paint process - this happens a lot to people who post here.
There are a, very, few times you might need to override paint, but I would always encourage you to try making it work with paintComponent first.
Check out
Performing custom painting
Painting in AWT and Swing (+1 to trashgod)
I am looking for the paint method implementation for a Java TextArea component (java.awt.TextArea).
I have read through the source code for the class as well as its super class (java.awt.TextComponent), but have not found a public void paint(Graphics g) method implementation, which I think means the class would be using the default Component#paint(Graphics) implementation, which doesn't make sense. Am I missing something here? How is a TextArea component painted?
TextArea is an AWT component, not a Swing component. It's thus what's called a heavyweight component, which means it's in fact implemented by a native component of the underlying platform/OS (i.e. a Windows/Gnome/Motif component, depending on the OS), called the peer of the component. The painting is thus done by the platform's native widget, and not by the component.
AWT Components is dinosauruses from last milenium, and only by back-compactible are there and still exists, please/better would be to change that to the Todays JComponents, all starts with "J" here is list of JComponents with tutorials, but for Swing's JComponents is there paintComponent(Graphics g) instead of paint(Graphics g)
method paint is still there but for deepest painting in XxxXxxUI, for example MetalButtonUI, but not for painting Image/Lines/Text ... and just try to avoid a similar examples from year 2000 and another very old examples, that's really wrong implemntation for Custom Painting in Java6's Swing,
here is your required tutorial and Java6 API
on this Forum are plenty threads about Painting Something in JComponents
EDIT: if you want to paint something then look for JLabel (is transparent by defalut), that best JComponent for 2D Graphics, examples for that here, and with paintComponent() method only