I use using WorldWind to plot data, and I also require a 2D interface as an overlay. I have been creating a new BufferedImage a few times per second to update the data, but this requires a lot of overhead. I'd like to redraw on an existing image to decrease the overall usage, both in terms of CPU and memory. I'm using this code before redrawing:
BufferedImage img = TrackingService.img.get(width).get(height);
g = img.createGraphics();
g.setComposite(AlphaComposite.getInstance(AlphaComposite.CLEAR));
g.fillRect(0,0,img.getWidth(),img.getHeight());
g.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER));
image = img;
ach element which can add to the UI returns a HashMap of BufferedImage to Point. Each BufferedImage and point is transformed into a ButtonAnnotation and added to an AnnotationLayer. Each x milliseconds, the system will:
layer.removeAllAnnotations();
layer.addAnnotations(buttonAnnotations);
redraw()
on the AWT Event queue. This works fine for markers, etc. but these images will never change from the first image I use. I've tried replacing the layer, disposing it, etc. I've tried writing the images to a debug file and noted that the BufferedImage is changing as expected. The problem is that WorldWind must be caching the images at some level. Since I am providing the same instance of BufferedImage to each new ButtonAnnotation, with a few modifications made using Graphics2D, it appears to be assuming that no changes have been made, when, in fact, there have been. This works perfectly fine if I use a new BufferedImage each time I want the data to change.
I have also tried the suggestions in This Question, and they did not work for me.
Related
SUMMARY:
Basically I want to be able to render items based on their Image/Batch/Sprite to speed up my game, but I also have to sort the entities based on y position so that it draws in the correct order.
QUESTION:
How can I do this theoretically? (block of code is nice, but reasoning is better, thanks!)
FULL SITUATION:
I am creating a 2.5 D side-scroller in which I have found that ~500 fps is decent for the early stage of development (on my crap computer at least) but i want this to be higher as I am going to be adding more aspects later (further reducing fps) so I want to be as optimized as I can right now.
What I was wondering is if it is possible to render all entities with the same image file at the same time, to save on time loading up the image files. The struggle I have is that I can't just sort entities by their image file (or at least not that I can think of, that's why I'm asking) because I also need to render them from back to front because its a 2.5 D game.
Right now I am storing the Images in a HashMap, so it isn't completely terrible, I just want to know what I can improve on.
EDIT: Also to note I am using the Jframe and Jpanel classes with Graphics for rendering
You don't need to post a block of code if you don't want. I just want more of the theoretical reasoning.
Thanks!
-Kore
One thought that comes to mind is that if you have an image that you know will be used a lot, you can cache it and that might help.
There are ways to directly reference an image file using BufferedImage and ImageIcon (I would link directly, but i don't have enough points :/ ).
Possibly mixing caching and a direct reference with the image file could help speed up the process. Along with the caching you could possibly find a way to group all of the objects that need the same image file together (this could be done by making an arrayList of all of the objects that use this sprite.), so once one of the objects renders the file, they all render it from the cache at that time. Then the cache is cleared for the next image.
Also, if you were to have variables that pointed to your sprites, then you could have the objects load the variable instead of them all having to point to the image file.
i.e.
String path = "Image1.jpg";
File file = new File(path);
BufferedImage image = ImageIO.read(file);
and then all of your objects referenced image for the source of their image. However, I am not sure if this would be any faster than individually pointing each object to the file, this was just a thought.
Hope some of this answers what you were asking. Good luck!
---edit---
So my next thought could be implemented using a parent class and or just another class that would hold an ArrayList. So the idea is that you don't want to have to use the method images.get(imgPath) every time you want to load an image.
import java.awt.image.BufferedImage;
import java.util.ArrayList;
import javax.swing.ImageIcon;
class SomeClass{
ImageIcon imgOne = new ImageIcon(new BufferedImage(images.get(imgPath)))
ImageIcon imgTwo = new ImageIcon(new BufferedImage(images.get(imgPathTwo)))
private ArrayList<ImageIcon> imagesHolder = new ArrayList<ImageIcon>(){{
add(imgOne);
add(imgTwo);
}};
public ImageIcon getImageIcon(int index){
return imagesHolder.get(index);
}
}
class test{
SomeClass imageHolder = new SomeClass();
JLabel label = new JLabel(imageHolder.getImageIcon(0));
JFrame f = new JFrame();
f.getContentPane().add(label);
}
In this, we have a class (someclass) whose object (that we only need one of) is storing every single image in an arraylist to the most processed state (imageIcon or whatever you are using can be used here) before actually putting it on the JFrame can create an object from to get all of the already rendered images.
This means that all you have to do at this point is add the image to the JFrame. you don't have to do a lot of the preprocessing of each image over and over again, because it's ready to just go on the JFrame.
While this does not particularly help a lot with rendering (cause most of this is processing of the image) it does help a lot with memory, because you are just creating 1 of each processed image and just repainting that same processed image.
hopefully this idea of processing all of the images once can help lead you to a way to have to only render the image once.
I'm currently using a Canvas with an associated BufferStrategy. How can I copy the contents (image) of the Canvas and save it to a BufferedImage. So far I've only tried
BufferedImage image = ...
g = image.createGraphics();
canvas.printAll(g); //or paintAll
However, it appears that only a 'blank' (filled with the background color) screen is being drawn; I it's assume because that's the default behavior of Canvas.paint(). Is there as way for me to retrieve the image currently on screen (the last one shown with BufferStrategy.show()), or do I need to draw to a BufferedImage and copy the image to the BufferStrategy's graphics. It seems like that would/could be a big slow down; would it?
Why (because I know someone wants to ask): I already have a set of classes set up as a framework, using Canvas, for building games that can benefit from rapidly refreshing screens, and I'm looking to make an addon framework to have one of these canvases tied into a remote server, sending it's displayed image to other connected clients. (Along the lines of remotely hosting a game.) I'm sure there are better ways to do this in given particular cases (e.g. why does the server need to display the game at all?) But I've already put in a lot of work and am wondering if this method is salvageable without modifying (to much of) the underlying Game framework code I already have.
I am implementing a board game where each player has several units and each unit is shown to a user using a common image which I read from a file using the following method. I read this image at application startup and going to use it later.
private static BufferedImage readBufferedImage (String imagePath) {
try {
InputStream is = IconManager.class.getClassLoader().getResourceAsStream(imagePath);
BufferedImage bimage = ImageIO.read(is);
is.close();
return bimage;
} catch (Exception e) {
return null;
}
}
Units differ with various colorful tokens located on the top of that common image.
Before I just add several commonImages to JPanel and tokens were implemented using JLabels which were floating on the top of commonImage
//at startup
ImageIcon commonImage = new ImageIcon(readBufferedImage("image.png"));
...
JPanel panel = new JPanel();
panel.add(commonImage);
panel.add(commonImage);
//located JLabels with token on the top of each commonImage
However, now I want to use JScrollPane instead of JPanel, so I think it is a better approach to drawString() and drawImage() to each commonImage before I show it to a user.
I estimate roughly a number of units as 20. So now every turn for every unit I would need to generate on-the-fly separate BufferedImage with various tokens configuration.
The question is whether I should cache already generated BufferedImages depending on token configuration to extract from cache if the image has been generated before with same configuration?
The question you ask depends on a few factors:
How long it takes to generate the image from scratch
How long it takes to check if the image was generated before
How large each image will be
The probability of the image being reused
So without having a good knowledge of your application, no one is going to be able to give you an answer accurate for every situation.
In general, if you're only moving tokens around, it should be quick to implement an update and the paintComponent method of the panel your drawing. If you save your base image, token image and the current resulting image (basically what you proposed), I wouldn't anticipate a performance problem. The key is to do your updating of the image in your custom update method, and always draw the current resulting image in the paintComponent method.
Update
For example, you can cache the current display using code similar to this:
private BufferedImage cachedImage;
...
#Override
public void paintComponent(Graphics g){
//If the image needs to be refreshed draw it to the cache first
if(cachedImage == null){
cachedImage = new BufferedImage(getWidth(), getHeight(), BufferedImage.TYPE_4BYTE_ABGR);
super.paintComponent(cachedImage.getGraphics());
}
//Draw the image from cache
g.drawImage(cachedImage, 0, 0, this);
}
When you want to clear the cache, in your method that does the update, you'd set cachedImage = null;
But in your situation,
Any performance problems at the scale of 200x200 you experience would have to do with the number of drawings you're doing. Since I'm guessing you're not concerned about a frames/second rate, I doubt you'll have performance problems (you can collect timings to see exactly how long it takes to draw - I'd guess well under 100 ms)
The easiest thing to do would be cache the images of the tokens and their strings (I'm assuming they rarely change), but still dynamically create the layout of the tokens. (Any other performance gains in your situation aren't going to be so easy).
Caching previous rendering of the screen will essentially break the swing display model (not much point in using it - just do the layout yourself). This actually applies to pretty much any caching of a container.
i'm trying to create a program that generates images for use as multi-screen backgrounds, i'm doing this targeted at windows (in my case, 7 so that basically i can get images to change without seeing the same image on two different screens)
in my program, i read multiple image input files and compile them into a single output image that is the total size of the desktop (including black areas not seen on screens)
my question is, what class/methods are good for cropping/resizing/pasting into a new image in java because i'm coming across so many image manipulation classes and they all seem to do one tiny thing.
i will not be modifying any of the images beyond resize or crop and putting it into a certain position in the new (initially blank) image.
code can be made available as i plan to release it at some later point for whoever may like/need it.
thank you in advance, if this question has been answered, my apologies but i DID have a look around.
I do not know if this is the best method, but it is quite easy:
// load an image
Image image = javax.imageio.ImageIO.read(new File("someimage.png");
// resize it
image = image.getScaledInstance(100, 100, Image.SCALE_SMOOTH);
// create a new image to render to
BufferedImage newimg = new BufferedImage(200,100,BufferedImage.TYPE_INT_ARGB);
// get graphics to draw..
Graphics2D graphics =newimg.createGraphics();
//draw the other image on it
graphics.drawImage(image,0,0,null);
graphics.drawImage(image,100,0,null);
graphics.fillOval(20,20,40,40); //making it a bit ugly ;)
//export the new image
ImageIO.write(newimg,"png",new File("output.png"));
//done!
For simplicity I dropped all checks, exception handling, etc.
I have an Eclipse RCP application that displays a lot (10k+) of small images next to each other, like a film strip. For each image, I am using a SWT Image object. This uses an excessive amount of memory and resources. I am looking for a more efficient way. I thought of taking all of these images and concatenating them by creating an ImageData object of the proper total, concatenated width (with a constant height) and using setPixel() for the rest of the pixels. However, the Palette used in the ImageData constructor I can't figure out.
I also searched for SWT tiling or mosaic functionality to create one image from a group of images, but found nothing.
Any ideas how I can display thousands of small images next to each other efficiently? Please note that once the images are displayed, they are not manipulated, so this is a one-time cost.
You can draw directly on the GC (graphics context) of a new (big) image. Having one big Image should result in much less resource usage than thousands of smaller images (each image in SWT keeps some OS graphics object handle)
What you can try is something like this:
final List<Image> images;
final Image bigImage = new Image(Display.getCurrent(), combinedWidth, height);
final GC gc = new GC(bigImage);
//loop thru all the images while increasing x as necessary:
int x = 0;
int y = 0;
for (Image curImage : images) {
gc.drawImage(curImage, x, y);
x += curImage.getBounds().width;
}
//very important to dispose GC!!!
gc.dispose();
//now you can use bigImage
Presumably not every image is visible on screen at any one time? Perhaps a better solution would be to only load the images when they become (or are about to become) visible, disposing of them when they have been scrolled off the screen. Obviously you'd want to keep a few in memory on either side of the current viewport in order to make a smooth transition for the user.
I previously worked with a Java application to create photomosaics, and found it very difficult to achieve adequate performance and memory usage using the java imaging (JAI) libraries and SWT. Although we weren't using nearly as many images as you mention, one route was to rely on a utilities outside of java. In particular, you could use ImageMagick command-line utilities to stitch together your mosaic, and the load the completed memory from disk. If you want to get fancy, there is also a C++ API for ImageMagick, which is very efficient in memory.