drawing to a JPanel without inheritance - java

Right now I'm working on a program that throws up a bunch of separate (generated at runtime) images, each in their own window. To do this i've tried this approach:
public void display(){
JFrame window = new JFrame("NetPart");
JPanel canvas = new JPanel();
window.getContentPane().add(canvas);
Graphics g = canvas.getGraphics();
Dimension d = getSize();
System.out.println(d);
draw(g,new Point(d.minX*50,d.maxY*50), 50);
window.setSize(d.size(50));
window.setResizable(false);
window.setDefaultCloseOperation(JFrame.HIDE_ON_CLOSE);
window.setVisible(true);
}
public void draw(Graphics g, Point startLoc, int scale){
// generate and draw the image
}
public Dimension getSize(){
//returns my own dimensions class
}
However, this throws a NullPointerException in draw, claiming that the graphics is null. is there any way to externally draw to a JPanel from outside it (not inherit from JPanel and override PaintComponent)? Any help would be appreciated.

If you are drawing your images at runtime you should use BufferedImage.
Create a BufferedImage, call getGraphics() on it to get its Graphics object, draw to it using the Graphics(2D) api, then call Graphics.dispose() (not strictly necessary but a good habit) and as the previous poster suggested either create an ImageIcon with it and put in a JLabel using setIcon() or subclass JPanel / JComponent and draw it in paintComponent

You're finding out that getGraphics() won't work in this way since the Graphics object obtained is null prior to the component being rendered, and even when it is not null, it is not stable and becomes invalid with each redraw. Possible options include:
Creating ImageIcon from each Image, placing the icon in a JLabel and displaying the JLabel.
Biting the bullet and extending JPanel or other JComponent (you don't say why you're trying to avoid this) and displaying the image in the JPanel's paintComponent method.
Doing the above, but first creating a BufferedImage which is displayed in the paintComponent(...) method. Then you can modify the BufferedImage during the program's run if you need to change the display, add new images,...

a program that throws up a bunch of separate (generated at runtime) images,
each in their own window
don't do it that this way, don't create a lots of JFrames, these Object stays in the memory, until current JVM instance exists, result from this concept pretty could be OutOfMemory exceptions
don't create lots of JFrames, create only one JFrame, rest of Containers could be JDialog or JWindow
don't create a new JFrames, JDialogs or JWindows on the runtime, re_use the existing Containers
put these images as Icons to the JList or maybe better would be look at CardLayout

Related

Java - paintComponents on a JPanel not working

I created a class that extends a JFrame and added a JPanel inside it, but the paintComponents() method doesn't draw anything on the JPanel. Heres the code for the paintComponents(), I chose to use double image buffering.
public void paintComponents(Graphics graphics) {
panel.paintComponents(graphics);
bufferedImage = createImage(sizeX, sizeY);
Graphics2D g = (Graphics2D) bufferedImage.getGraphics();
for (ImageData myImage : imageData) {
g.drawImage(myImage.getImage(), myImage.getX(), myImage.getY(), null);
}
graphics.drawImage(bufferedImage, 0, 0, null);
}
Is there anything wrong with this? Btw, I tried paint() and it worked but I dont think it's the proper way to do this.
Thanks for your time. :)
Do not extend a top level component such as a JFrame. Instead keep an instance of a frame, and add a panel to that. All custom painting or addition of components is done in the panel.
When doing custom painting in a panel, do it in the paintComponent method (not paintComponents do not override that).
Other tips
Remember to call super.paintComponent(g);. This is important to ensure that borders and padding etc. are accounted for.
Swap null for this. Every JComponent is an ImageObserver.
please note that JFrame is NOT a JComponent! In fact, the paintComponents(Graphics) method is NEVER called. A fix would be subclassing JPanel and adding your subclassed panel to the frame as the content pane. In the panel override the paintComponents(Graphics) method.

Using Graphics outside the paintComponent

Let's say we have the following situation:
JPanel panelp=new JPanel();
paintSomething(panelp.getGraphics();
and somewhere else in a different object, the method:
void paintSomething(Graphics g){ /*code*/ }
I don't want to override paintComponent method of panelp. How can I paint something to panelp from the method paintSomething using the Graphics of panelp?
whatever.getGraphics() is snapshot is the snapshot that will go away when
after first repaint
JComponets are repainted internally from Mouse or Key Events, these events are implemented in the concrete JComponets API
simple example for usage of whatever.getGraphics() is printing to the printer or saving current GUI as printscreen to the e.g. JPEG or PGN File
basic stuff is described in the 2D Graphics
You could draw your stuff in the paintSomething into a BufferedImage which you can then draw to the panel by overriding paintComponent

Why is attaching a JPanel better?

I've just started coding video games and I've heard that doing all your drawing on a JPanel and attaching that panel onto a JFrame is better than simply drawing onto the JFrame. I was just wondering why is this better?
It is better for various reasons, including:
In most Swing components, custom painting is achieved by overriding the paintComponent(Graphics) method. Top-level Swing containers (e.g. JFrame, JApplet, JWindow) have only paint(Graphics). As a result of the common method for painting, people who answer often forget about this difference between common and top-level components, and therefore suggest silly advice. ;)
A JComponent can be added to a JFrame, or a JApplet, or a JDialog, or a constraint of a layout in a JPanel, or a JInternalFrame, or a.. Just when you think your GUI is complete, the client says "Hey, wouldn't it be great to throw in a tool-bar & offer it as an applet as well?" The JComponent approach adapts easily to that.
As explained (complete with code!) by Richante, it is easier to calculate the co-ordinates required for painting the custom component, and if it has a preferred size, to size the JFrame to be 'exactly the right size' to contain the GUI (using pack()). That is especially the case when other components are added as well.
Now, two minor disagreements with the advice offered.
If the entire component is custom painted, it might be better to simply put a BufferedImage inside an ImageIcon/JLabel combo. Here is an example of painting to an image. When it comes time to update it:
Call getGraphics() for a Graphics or createGraphics() for a Graphics2D
Draw the custom painting to that graphics instance
Dispose of the graphics instance
Call repaint() on the label.
It is an easy way to do Double Buffering.
Let me elaborate a bit. In video games, to avoid the flicker caused by redrawing and display smoother graphics, people usually use double buffering. They create an offscreen surface, draw everything on that and then display the entire off-screen surface on the screen in one go.
In Java2D and Swing, the easiest way to do this, is to simply do your game sprite drawing on a JPanel, and then add the JPanel to a JFrame.
Secondly, by drawing things on a JPanel, you allow more GUI widgets and other graphical objects to be displayed on the JFrame without having to paint them manually in the game loop. For example buttons, menus, other panels, even other rendering JPanels.
Thirdly, it allows you to use automatically translated co-ordinates for your game. You can draw everything from the top-left to the bottom-right without having to worry about the window manager specific things like window border-widths, task panes, titles etc.!
Moreover, this is not just a convention only used by Game Programmers in Java. Creating a separate Game Board, Render Panel or Graphics Widget is quite popular when programming games using a library with an internal mainloop such as a GUI Toolkit. You can use a User Form in Windows Forms and a Drawing Board in GTK+.
The JFrame includes things like the menu, title bar and border. Therefore, when you refer to coordinates you have to account for these. You might also decide to add a menu bar, or some other components, to the frame. If your painting is all in a JPanel, then this won't change how you need to refer to coordinates.
For example, try:
public class Test extends JFrame {
public Test() {
super();
setVisible(true);
setBounds(100, 100, 200, 100);
}
#Override
public void paint(Graphics g) {
g.fillRect(0, 0, 50, 50);
}
public static void main(String[] args) {
new Test();
}
}
and you will see that the black square is not square! Because (0, 0) is the top left corner of the entire frame, not the corner of the visible area.

Pictures in a JPanel

I'm trying to write an application where I want to add different pictures on a Jpanel. Everything works fine except for the JPG format which displays very bad quality images.
This is how I do the drawing :
class draw extends Canvas
{
Dimension canvasSize = new Dimension(400, 400);
String fileName;
public void paint(Graphics g)
{
if(this.fileName!=null)
{
Toolkit toolkit = Toolkit.getDefaultToolkit();
Image img = toolkit.getImage(fileName);
g.drawImage(img, 0, 0, this);
}
}
public void setFileName(String name)
{
this.fileName=name;
}
public Dimension getMinimumSize()
{
return canvasSize;
}
public Dimension getPreferredSize()
{
return canvasSize;
}
}
Is there a way such that JPG format is covered ?
This is probably because you're stretching (or compressing) the image to the size of the canvas. JPEG images don't look great when you scale them, particularly if you're scaling up. Try an image that's the same size as (or close to) your canvas. You can also get the height and width of the JPEG from the Image class and display it in its original dimensions. Sun's Drawing an Image tutorial shows how to do this.
The posted code indicates that the OP is painting the image at its original size. So my comments about the code:
a) You say you want to add the image to a JPanel, yet for some reason you are extending Canvas. Stick with Swing components. Then if you need to do custom painting you would override the paintComponent() method NOT the paint method.
b) When you do use custom painting, you should never read the image in the painting method. This method can be called numerous times. It possible that the image has not been completely read into memory. I know Swing will automatically repaint as more of the image is read, I'm not sure how the AWT Canvas works.
c) Also, when overriding paint methods don't forget to invoke super.paint(), super.paintComponent() or you may get unexpected results.
d) However, based on the posted code there is no need to even do custom painting (since you are drawing the image at its actual size). Just create an ImageIcon from the image and add the Icon to a JLabel. Then you just add the label to the GUI.
I suggest you read the section from the Swing tutorial on How to Use Icons. If the image quality is poor then the problem is probably with your image because now you are using standard code, not custom code.

How to add an image to a JPanel?

I have a JPanel to which I'd like to add JPEG and PNG images that I generate on the fly.
All the examples I've seen so far in the Swing Tutorials, specially in the Swing examples use ImageIcons.
I'm generating these images as byte arrays, and they are usually larger than the common icon they use in the examples, at 640x480.
Is there any (performance or other) problem in using the ImageIcon class to display an image that size in a JPanel?
What's the usual way of doing it?
How to add an image to a JPanel without using the ImageIcon class?
Edit: A more careful examination of the tutorials and the API shows that you cannot add an ImageIcon directly to a JPanel. Instead, they achieve the same effect by setting the image as an icon of a JLabel. This just doesn't feel right...
If you are using JPanels, then are probably working with Swing. Try this:
BufferedImage myPicture = ImageIO.read(new File("path-to-file"));
JLabel picLabel = new JLabel(new ImageIcon(myPicture));
add(picLabel);
The image is now a swing component. It becomes subject to layout conditions like any other component.
Here's how I do it (with a little more info on how to load an image):
import java.awt.Graphics;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.imageio.ImageIO;
import javax.swing.JPanel;
public class ImagePanel extends JPanel{
private BufferedImage image;
public ImagePanel() {
try {
image = ImageIO.read(new File("image name and path"));
} catch (IOException ex) {
// handle exception...
}
}
#Override
protected void paintComponent(Graphics g) {
super.paintComponent(g);
g.drawImage(image, 0, 0, this); // see javadoc for more info on the parameters
}
}
Fred Haslam's way works fine. I had trouble with the filepath though, since I want to reference an image within my jar. To do this, I used:
BufferedImage wPic = ImageIO.read(this.getClass().getResource("snow.png"));
JLabel wIcon = new JLabel(new ImageIcon(wPic));
Since I only have a finite number (about 10) images that I need to load using this method, it works quite well. It gets file without having to have the correct relative filepath.
I think there is no need to subclass of anything. Just use a Jlabel. You can set an image into a Jlabel. So, resize the Jlabel then fill it with an image. Its OK. This is the way I do.
You can avoid rolling your own Component subclass completely by using the JXImagePanel class from the free SwingX libraries.
Download
JLabel imgLabel = new JLabel(new ImageIcon("path_to_image.png"));
You can subclass JPanel - here is an extract from my ImagePanel, which puts an image in any one of 5 locations, top/left, top/right, middle/middle, bottom/left or bottom/right:
protected void paintComponent(Graphics gc) {
super.paintComponent(gc);
Dimension cs=getSize(); // component size
gc=gc.create();
gc.clipRect(insets.left,insets.top,(cs.width-insets.left-insets.right),(cs.height-insets.top-insets.bottom));
if(mmImage!=null) { gc.drawImage(mmImage,(((cs.width-mmSize.width)/2) +mmHrzShift),(((cs.height-mmSize.height)/2) +mmVrtShift),null); }
if(tlImage!=null) { gc.drawImage(tlImage,(insets.left +tlHrzShift),(insets.top +tlVrtShift),null); }
if(trImage!=null) { gc.drawImage(trImage,(cs.width-insets.right-trSize.width+trHrzShift),(insets.top +trVrtShift),null); }
if(blImage!=null) { gc.drawImage(blImage,(insets.left +blHrzShift),(cs.height-insets.bottom-blSize.height+blVrtShift),null); }
if(brImage!=null) { gc.drawImage(brImage,(cs.width-insets.right-brSize.width+brHrzShift),(cs.height-insets.bottom-brSize.height+brVrtShift),null); }
}
There shouldn't be any problem (other than any general problems you might have with very large images).
If you're talking about adding multiple images to a single panel, I would use ImageIcons. For a single image, I would think about making a custom subclass of JPanel and overriding its paintComponent method to draw the image.
(see 2)
JPanel is almost always the wrong class to subclass. Why wouldn't you subclass JComponent?
There is a slight problem with ImageIcon in that the constructor blocks reading the image. Not really a problem when loading from the application jar, but maybe if you're potentially reading over a network connection. There's plenty of AWT-era examples of using MediaTracker, ImageObserver and friends, even in the JDK demos.
I'm doing something very similar in a private project I'm working on. Thus far I've generated images up to 1024x1024 without any problems (except memory) and can display them very quickly and without any performance problems.
Overriding the paint method of JPanel subclass is overkill and requires more work than you need to do.
The way I do it is:
Class MapIcon implements Icon {...}
OR
Class MapIcon extends ImageIcon {...}
The code you use to generate the image will be in this class. I use a BufferedImage to draw onto then when the paintIcon() is called, use g.drawImvge(bufferedImage); This reduces the amount of flashing done while you generate your images, and you can thread it.
Next I extend JLabel:
Class MapLabel extends Scrollable, MouseMotionListener {...}
This is because I want to put my image on a scroll pane, I.e. display part of the image and have the user scroll around as needed.
So then I use a JScrollPane to hold the MapLabel, which contains only the MapIcon.
MapIcon map = new MapIcon ();
MapLabel mapLabel = new MapLabel (map);
JScrollPane scrollPane = new JScrollPane();
scrollPane.getViewport ().add (mapLabel);
But for your scenario (just show the whole image every time). You need to add the MapLabel to the top JPanel, and make sure to size them all to the full size of the image (by overriding the GetPreferredSize()).
This answer is a complement to #shawalli's answer...
I wanted to reference an image within my jar too, but instead of having a BufferedImage, I simple did this:
JPanel jPanel = new JPanel();
jPanel.add(new JLabel(new ImageIcon(getClass().getClassLoader().getResource("resource/images/polygon.jpg"))));
Create a source folder in your project directory, in this case I called it Images.
JFrame snakeFrame = new JFrame();
snakeFrame.setBounds(100, 200, 800, 800);
snakeFrame.setVisible(true);
snakeFrame.add(new JLabel(new ImageIcon("Images/Snake.png")));
snakeFrame.pack();
You can avoid using own Components and SwingX library and ImageIO class:
File f = new File("hello.jpg");
JLabel imgLabel = new JLabel(new ImageIcon(file.getName()));
I can see many answers, not really addressing the three questions of the OP.
1) A word on performance: byte arrays are likely unefficient unless you can use an exact pixel byte ordering which matches to your display adapters current resolution and color depth.
To achieve the best drawing performance, simply convert your image to a BufferedImage which is generated with a type corresponding to your current graphics configuration. See createCompatibleImage at https://docs.oracle.com/javase/tutorial/2d/images/drawonimage.html
These images will be automatically cached on the display card memory after drawing a few times without any programming effort (this is standard in Swing since Java 6), and therefore the actual drawing will take negligible amount of time - if you did not change the image.
Altering the image will come with an additional memory transfer between main memory and GPU memory - which is slow. Avoid "redrawing" the image into a BufferedImage therefore, avoid doing getPixel and setPixel at all means.
For example, if you are developing a game, instead of drawing all the game actors to a BufferedImage and then to a JPanel, it is a lot faster to load all actors as smaller BufferedImages, and draw them one by one in your JPanel code at their proper position - this way there is no additional data transfer between the main memory and GPU memory except of the initial transfer of the images for caching.
ImageIcon will use a BufferedImage under the hood - but basically allocating a BufferedImage with the proper graphics mode is the key, and there is no effort to do this right.
2) The usual way of doing this is to draw a BufferedImage in an overridden paintComponent method of the JPanel. Although Java supports a good amount of additional goodies such as buffer chains controlling VolatileImages cached in the GPU memory, there is no need to use any of these since Java 6 which does a reasonably good job without exposing all of these details of GPU acceleration.
Note that GPU acceleration may not work for certain operations, such as stretching translucent images.
3) Do not add. Just paint it as mentioned above:
#Override
protected void paintComponent(Graphics g) {
super.paintComponent(g);
g.drawImage(image, 0, 0, this);
}
"Adding" makes sense if the image is part of the layout. If you need this as a background or foreground image filling the JPanel, just draw in paintComponent. If you prefer brewing a generic Swing component which can show your image, then it is the same story (you may use a JComponent and override its paintComponent method) - and then add this to your layout of GUI components.
4) How to convert the array to a Bufferedimage
Converting your byte arrays to PNG, then loading it is quite resource intensive. A better way is to convert your existing byte array to a BufferedImage.
For that: do not use for loops and copy pixels. That is very very slow. Instead:
learn the preferred byte structure of the BufferedImage (nowadays it is safe to assume RGB or RGBA, which is 4 bytes per pixel)
learn the scanline and scansize in use (e.g. you might have a 142 pixels wide image - but in the real life that will be stored as a 256 pixel wide byte array since it is faster to process that and mask the unused pixes by the GPU hardware)
then once you have an array build according to these principles, the setRGB array method of the BufferedImage can copy your array to the BufferedImage.

Categories