My question is whether the use of setOpaque(false), which I've come to use with JPanel to layout UI in Swing, impacts painting performance more than keeping everything opaque (where isOpaque() returns true).
I'm not very familiar with how Swing renders UI but I would guess that if a JComponent is not opaque it would be harder to render what's behind the component then to simply paint an opaque background on the component.
Yes it does add extra work when painting but I doubt you would have to worry about it.
Basically, whenever you repaint a component that is transparent you need to go up the chain to find a parent that is not opaque and then paint that component first, before painting the child component.
So the bottom line is don't worry about it. If you have a reason to use transparency then use it. If you don't have a reason then you shouldn't be using it.
You may want to check out Background With Transparency. It goes into a little more detail on what the opaque property means and how it affects painting and the problem you will have if you do use a transparent background.
Related
I am not asking how to use Java swing nor I am asking for suggestion on using layout managers. I am just curious how Java behaves.
All along it has been a myth and many people speculate that Java automatically repaints the components when you resize the frame OR mouse over the components in the frame.
So my question is: Is it true that Java does the repainting automatically when we carry out one of the above actions?
There has been several post with similar title such as: Java repainting a component at mouse-over.
But no one can give a definite answer whether Java does the repainting automatically upon certain user actions (such as resizing & mouse over).
All along it has been a myth and many people speculate
There is no myth or speculation.
automatically repaints the components when you resize
This makes sense because the layout manager is invoked and the size or location may change which means some components may need to be repainted.
automatically repaints the components when you mouse over the components in the frame.
It depends on the component. If a MouseListener has been added to the component to do special processing (ie. rollover a button) then the component may be repainted, otherwise nothing happens. But there is no default painting unless it has been specifically added as part of the UI for the component.
These question is easily verified. Just override the paintCompent() method of your components to display a message when the component is painted and see what happens.
im making a java swing game. I heard that swing components don't use active rendering(you can only override paint methods), and for that reason, i have been using BufferStrategy with Canvas. Now i have discover the getGraphics() method from JComponent and JPanel. If we can do active render in swing components, why game tutorials still override paint() and paintComponent()?
Don't EVER use getGraphics, it can return null and is nothing more the a snap-shot of the last paint cycle.
Anything you paint to it will be removed on the next paint cycle. In Swing you DON'T control the paint process and a paint cycle could be initiated for any number of reasons, many of which you don't have control over or would notified of (other then when paint was called)
The basic answer is, if you want control over the paint process, you MUST use a BufferStrategy or implement you own off screen drawing routines. There is NO means by which you can achieve a true active painting process within the Swing API, you can fake it to a certain extent, but Swing will still be able to perform it's own painting cycles when it sees fit.
Have a look at Painting in AWT and Swing and Performing Custom Painting for more details about how painting works in Swing
Can we draw things on any Swing GUI component? If yes then Why should we use a panel as
a canvas for drawings rather than a label or a button?
Start by taking a look at Perfoming Custom Painting for details about how painting is done in Swing
The second part of your question depends on what it is you want to achieve.
Generally speaking, you shouldn't paint directly onto existing components because painting is actually done by the UI delegate. If you want to change the look and feel of these components, you should consider creating a custom UI delegate to perform the painting as you need. This ensures that the painting is done correctly.
This doesn't stop you from overriding its paintComponent method, but with complex controls like buttons, lists, tables and trees, you may find it difficult to achieve the results you want.
Equally, tables, trees and lists use renderers to provide customised output
Lets assume a label is a price tag and a panel is a piece of paper. Do you usually paint() on buttons and price tags in real life? :)
Labels and Buttons have a lot of extra "features" and capabilities that will probably get in your way or bite you with bugs. JPanel is, almost literally, a clean slate on which to start.
I'm learning Java as part of my degree but its very brief but what ever I do I like to make sure I atleast have some understanding.
Until now anything that I want displayed on the screen is put into the paintcomponent method of the JPanel.
However, I have drawn out some parts of my layout which never change, and only a certain thing in the middle rotates.
I have a timer which calls repaint().
If I correct in thinking that everything including the components that never change are being removed and then redrawn and the whole paintcomponent method is being run every time.
To me I feel like I should (or there must be) a way where the static stuff is moved out / is only drawn once, and only the parts that I specifically want to be redrawing should stay in the paintcomponent method?
Is this correct or am I not fully understanding something?
I am assuming that you are not adding GUI components in the paintComponent method, right?
Components are not "removed" during a repaint
Better to put the stable part of any image into a single background BufferedImage and draw the BufferedImage in the paintComponent method. This can make for more efficient painting.
Consider calling an overload of repaint(...) that sets a bounding rectangle for the region to be painted.
Is there a way to change the default background painting of all instances of a swing component (a JPanel for example) to paint with a gradient background? Or would I need to create an extension of JPanel that paints with a gradient and then use that instead of JPanel everywhere in my app?
IMHO, it would be easier to just subclass the Swing component and override its paintComponent method to do the gradient painting. And then, as you said, use this custom component throughout the application.
It could be tricky using the UI properties since they may not be consistent across all LaFs.
It is not entirely clear what scope you intend. Did you mean by class (so all JPanel instances follow the new painting scheme), or do you mean all components in a Container (e.g. everything in Frame)?
There are possibilities to do this depending on component class, the places where you can hook into are the Look and Feel, and on a by component instance base, either the paintComponent() method, or if you need to replace the standard look of an existing component where you can not overwrite the method because you have no control over it, by providing your own UI class (look at Component.setUI) after the component has been created.
Except for the overwrite paintComponent approach neither is simple to implement. For most applications the simple approach is the best :)