I do not know java (usually write in c)
How can I do efficiently some way of blitting
pixel array content onto a window in java?
I need (in loop) blit pixels[][] onto a window
I could use something like
pixels[][] -> MemoryImageSource -> Image -> drawImage
but creating and deleting MemoryImageSource and Image
in every frame seems strange to me - how it can be
done simply and reasonably efficiently? Could someone
give a code example, tnx
Normally in Java it's easier to work with the native Image types and use their derived graphics. Behind the scenes Java uses blits as well, so the higher level abstractions is made to easen the workload.
But if there's no way to abstract on the pixel data you can use Raster and WritableRaster (where you can replace portions of the array) as an alternative to your solution. These rasters can be used with a BufferedImage which then can be drawn using the drawImage method you mentioned. I found one way of doing it here which basically creates the Image and then retrieves the raster for future manipulation.
int x, y = 100;
BufferedImage image = new BufferedImage(x, y, BufferedImage.TYPE_INT_RGB);
WritableRaster raster = image.getRaster();
That raster (or just small areas of it) can then be manipulated and repainted.
This might improve performance slightly since the distance from you pixel-array to the screen is shorter. But I think very few people fully understands the entire depths of the AWT api - and it all depends on the native implementations of course - so my idea contains a healthy part of speculation ;-)
But I hope it helped..
For speed, you can pre-compute variations of the ColorModel, as shown in this example.
Related
I'm creating a java implantation of http://alteredqualia.com/visualization/evolve/, as a hobby project. I'm using HW-accelerated Graphics2D to draw the polygons on a volatile image, I then want to create a texture from the volatileImage so I can use glReadPixels to compare the generated image to the original (which is also a texture).
I spent the last 2 hours spitting through various Textures documentations, but there doesn't seem to an easy way to create a texture out of a volatileImage. Did I miss something here, or is this just not possible? I know you can convert the volatileImage to a BufferedImage and then create the Texture, but this method is very slow. Which is a bad thing considering performance is crucial for this program.
There is no direct way because a VolatileImage has no API for obtaining the image data, except by making a copy using snapshot().
In practice, simply use a BufferedImage from the start - there is some magic under the hood of BufferedImage that will make use of hardware acceleration where possible. One thing you must avoid is obtaining a reference of a BufferedImage's DataBuffer, that may break the acceleration.
I am looking for the simplest (and still non-problematic) way to resize a BufferedImage in Java.
In some answer to a question, the user coobird suggested the following solution, in his words (very slightly changed by me):
**
The Graphics object has a method to draw an Image while also performing a resize operation:
Graphics.drawImage(Image, int, int, int, int, ImageObserver)
method can be used to specify the location along with the size of the image when drawing.
So, we could use a piece of code like this:
BufferedImage originalImage = // .. created somehow
BufferedImage newImage = new BufferedImage(SMALL_SIZE, SMALL_SIZE, BufferedImage.TYPE_INT_RGB);
Graphics g = newImage.createGraphics();
g.drawImage(originalImage, 0, 0, SMALL_SIZE, SMALL_SIZE, null);
g.dispose();
This will take originalImage and draw it on the newImage with the width and height of SMALL_SIZE.
**
This solution seems rather simple. I have two questions about it:
Will it also work (using the exact same code), if I want to resize an image to a larger size, not only a smaller one?
Are there any problems with this solution?
If there is a better way to do this, please suggest it.
Thanks
The major problem with single step scaling is they don't generally produce quality output, as they focus on taking the original and squeezing into a smaller space, usually by dropping out a lot of pixel information (different algorithms do different things, so I'm generalizing)
Will drawGraphics scale up and down, yes, will it do it efficiently or produce a quality output? These will come down to implementation, generally speaking, most of the scaling algorithms used by default are focused on speed. You can effect these in a little way, but generally, unless you're scaling over a small range, the quality generally suffers (from my experience).
You can take a look at The Perils of Image.getScaledInstance() for more details and discussions on the topic.
Generally, what is generally recommend is to either use a dedicated library, like imgscalr, which, from the ten minutes I've played with it, does a pretty good job or perform a stepped scale.
A stepped scale basically steps the image up or down by the power of 2 until it reaches it's desired size. Remember, scaling up is nothing more then taking a pixel and enlarging it a little, so quality will always be an issue if you scale up to a very large size.
For example...
Quality of Image after resize very low -- Java
Scale the ImageIcon automatically to label size
Java: JPanel background not scaling
Remember, any scaling is generally an expensive operation (based on the original and target size of the image), so it is generally best to try and do those operations out side of the paint process and in the background where possible.
There is also the question whether you want to maintain the aspect ratio of the image? Based on you example, the image would be scaled in a square manner (stretched to meet to the requirements of the target size), this is generally not desired. You can pass -1 to either the width or height parameter and the underlying algorithm will maintain the aspect ratio of the original image or you could simply take control and make more determinations over whether you want to fill or fit the image to a target area, for example...
Java: maintaining aspect ratio of JPanel background image
In general, I avoid using drawImage or getScaledInstance most of the time (if your scaling only over a small range or want to do a low quality, fast scale, these can work) and rely more on things like fit/fill a target area and stepped scaling. The reason for using my own methods simply comes down to not always being allowed to use outside libraries. Nice not to have to re-invent the wheel where you can
It will enlarge the original if you set the parameters so. But: you should use some smart algorithm which preserves edges because simply enlarging an image will make it blurry and will result in worse perceived quality.
No problems. Theoretically this can even be hardware-accelerated on certain platforms.
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.
I have been working on a Java 2D game for a little while. It is a raster graphics system with an array of pixels (integers).
private BufferedImage image = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB);
private int[] pixels = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();
I then create an array of integers separately, manipulate it with the screen objects (rendered from external image files, such as .png), then copy that array into my main one, which is projected on the screen. I found no performance difference (and really didn't expect to) in using array copying methods over iteration. Regardless, the graphics render well and the game is coming along swimmingly.
However, I have found this to be extremely CPU intensive. My activity monitor says that the application is using more than 100% of my CPU. This is obviously because I am iterating through a pixel array (76k integers) each update (60 times per second).
I chose this technique for educational purposes. This is a personal project and I simply wanted to get insight into Java graphics. I am, by no means, married to this rendering technique.
My question comes in three related parts...
Obviously there is a better way to do this. What libraries/frameworks would do it better?
Will those libraries essentially do the same thing (loop through the pixels), just in a more efficient way?
Is there a way I can optimize this technique without using external tools, or is it just not worth it?
OpenGL is most often associated with 3D graphics applications, but it can also be used for 2D applications. Using an orthographic projection and textured quads to take the place of sprites and background images, you can construct the graphics and interface for a game with absolutely no 3D elements at all, despite the fact that the drawing is being done, in a sense, in 3D.
I have no experience using OpenGL in Java. However, I know that it is possible using the LWJGL library and possibly others. You should check it out if you want to drastically improve your graphics performance.
To answer your second question, OpenGL in this application actually works very differently from your approach, using the same techniques it would use to draw textured polygons in 3D rather than simple block image transfers into a framebuffer, though pixel data can be accessed and manipulated.
Here's an example of 2D graphics using OpenGL with C, from a game project I never finished but nevertheless may serve as a good visual example of what I'm talking about. In this case, I did not use an orthographic projection, but rather a perspective matrix to get parallax effects by drawing the various layers at different depths in 3D space.
I have a BufferedImage with an IndexColorModel. I need to paint that image onto the screen, but I've noticed that this is slow when using an IndexColorModel. However, if I run the BufferedImage through an identity affine transform it creates an image with a DirectColorModel and the painting is significantly faster. Here's the code I'm using
AffineTransformOp identityOp = new AffineTransformOp(new AffineTransform(), AffineTransformOp.TYPE_BILINEAR);
displayImage = identityOp.filter(displayImage, null);
I have three questions
1. Why is painting the slower on an IndexColorModel?
2. Is there any way to speed up the painting of an IndexColorModel?
3. If the answer to 2. is no, is this the most efficient way to convert from an IndexColorModel to a DirectColorModel? I've noticed that this conversion is dependent on the size of the image, and I'd like to remove that dependency.
Thanks for the help
This is too long for a comment...
Are you sure that the BufferedImage you're creating are the best depending on the OS you're on? You should always create a "compatible" BufferedImage. The fastest on, say, Windows, may be TYPE_INT_ARGB but this is not true on OS X and vice-versa.
Something like this (ouch, the Law of Demeter hurts ;) :
GraphicsEnvironment
.getLocalGraphicsEnvironment()
.getDefaultScreenDevice()
.getDefaultConfiguration()
.createCompatibleImage(width, height,Transparency.TRANSLUCENT)