VolatileImage question - Help a newbie out here :)

Java 2D
#1

Alriiiight.

I don’t know why, but I’m not seeing anyone complain of the fact you cannot manipulate single pixels in VolatileImage? ???

For instance, I set up a little stress test, I added a few dozen squares that render in random locations, and a few rotating cubes in the middle of the screen. With BufferedImage techniques I couldn’t get above 100fps, and I have a decent comp (specs below). Then I read about VolatileImage, my heart soared! I implemented it and SHAZAM! 500-600fps max.

My pc isn’t the problem either, it’s a 3.2ghz, 512mb ram, and a Geforce FX 5500.

Now I wanna mess around with some pixel-effects, like texture mapping etc. I tried using things like drawRect/drawLine etc. Drawing a simple 300x300 area with pixels using the aforementioned functions results in a drop of 480 fps. Why is it that a simple pixel set function is not available to VolatileImage? I mean, VI is meant to be better for rendering etc, yet it doesn’t support something so simple. :frowning:

Anyways, this isn’t a rant. I’m just asking if anyone knows of a way to get around this problem? Is it possible to perhaps write to a BufferedImage first then copy it into the VolatileImage?

Thanks, Sam.

#2

you’re right, this is not possible or at least not very efficient. VolatileImage can be passed to a PixelGrabber but performance is TERRIBLE if you use an accerlated pipeline.

The main-reason is that pixel-operations can not be accerlated efficiently since there must be passed data from RAM -> Video-ram which is slow because of the many busses and so on… (data needs to be passed from your java-program to video-memory which is not efficient,regardless wether VImage is used or not)

The best is that you create an bufferediamge where you can modify pixels (I would recommend to use the setPixels(int[]… Method to set all pixels at once) and later on blit this image to the VolatileImage but its still very SLOW compared with accerlated operations.

lg clemens

#3

Hi Linuxhippy (awesome name btw :P),

Thanks for the reply, I had a hunch this was the case. I’m starting to wonder whether Java2D has any real practical applications in regards to an applet… :frowning:

#4

Glad you like my nick, I chose it when I was 13 :wink:

Why?

Java2D abstracts all the ugly downsides of the pipelines it relies on and offers great performance for most operations, its even much faster than GDI for many more complex operatios requiring 1/5 of GDIs code not to mention Direct3D or OpenGL where you need to have a lot of knowledge to get descent performance at all (not to metion incompatibilities for standards - hello ATI) so with java2d you can things easily native windows apps dream about it.

In our school we had a project for vizualitation of waves and they did a lot direct pixel manipulation, GDI failes so they choose OpenGL with the effect that they had it to pesent it on their own laptop since it didn’t work on the presetation laptop. They needed 2 months to write the whole stuff - the same with Java2D I would have done in 1/2 hour with better performance and many accerlated backends to support even the most crappies hardware.

Be happy with what you get for free, its really very great - trust me.

lg Clemens

#5

Yeah, but Flash has even more abstraction when it comes down to 2D stuff in a webpage. Not to mention I’ve seen some nice little 3D thigns done in Flash…

My point being that no optimized pixel set operation makes for very limited power :frowning:

#6

no pipeline allowed fast per-pixel manipulations, regardless wether you choose OpenGL, Direct3D, X11 or GDI.
Java cannot do things not provided by operating systems.

since you compared java and applets with flash - flash isn’t really useful for anything than “applets” or stupid “applet”-like applications.

btw. flash has much less features regarding to rendring - simple line drawing is so slow that it can be easily beaten by not accerlated java2d-pipelines. With abstraction I ment same commands on every platform, not vector stuff or anything like that. btw direct pixel manipulations are impossible with flash :wink:

lg Clemens

#7

Hehe, well you’re right of course.Can you think of any way to implement a basic particle system in java 2d though?

With no pixel operation it makes for some rather messy stuff, of course you could use images, but when you get to trying to scale and manipulate particles, things get ugly. Or do they? Enlighten meeee ;D

#8

well, this really depends on the pipeline you’re using. Scaling images is almost free on OpenGL and also on Direct3D but it can be quite costly on GDI or X11.

I would just try the unaccerlated pixel-access over buffered images I explained - for small images this is fast enough and particle-systems drawing over the whole screen are quite seldom :wink:
On my rather ugly GF488Go card in OGL mode it takes ~20ms to draw a unaccerlated image with 500x500 (SW->Surface blit).

lg Clemens

#9

Pardon my ignorance, but what is OGL mode?

Are you referring to JOGL? Is it possible to use it’s pipeline with Java2D? That would be rather nice :slight_smile:

#10

no, java2d has several supported backends: gdi/directdraw; direct3d, x11, OpenGL - this is not related with JOGL.

Basically you can see: Accerlated features are REALLY fast under accerlated pipelines (direct3d, OPenGL) but software-operations can really destroy performance on those pipelines so its always good to have a look what’s happening under the hood:
-Dsun.java2d.trace=count (as command-line argument). sun.java2d.loops is software

I would suggest downloading the lastest mustand-snapshots, a lot has changed since 1.5: j2se.dev.java.net

enable OpenGL pipeline (preffered by me): -Dsun.java2d.opengl=True
enable D3D pipeline (hmm…): -Dsun.java2d.d3d=true

lg Clemens

#11

Do those switches work with Applets?

#12

Actually I think I found a decent enough solution to this problem.

I tried MemoryImageSource before, maybe I did something wrong before, 'cos it didn’t work well… I just tried implementing it again in my graphics subsystem, and it works great! Filled a 500x500 image with pixels, and blitted it to my backbuffer. I’m doing this every render frame and still tossing out 200fps max! Hurray!

#13

you are blitting the same image over and over, don’t you?
Try to create a new image every paint, otherwise your image gets accerlated and you do not see the effect of direct-pixel access at all.

Btw. MemoryImageSource is part of the very old ImageProducer/Consumer API introduced in Java-1.1 and isn’t well supported anymore. The more advanced the rendering backends become the poorer is the support for those APIs.
What do you mean with “implementing it again in my graphics subsystem”? You just ran it on another backend?
Why don’t you what I’ve told you, are you analphabethic?

1.) Create a bufferedImage of TYPE_INT_ARGB
2.) Create an int[] of the same size
3.) set the pixels in the array
4.) set the pixels of the image using “setRGB(int startX, int startY, int w, int h, int[] rgbArray, int offset, int scansize)”
5.) Blit the image.

Clemens

#14

“analphabethic”?! :o Are you trying to show off your vocabulary, or hurt my feelings? Or both?

Besides, I tried using the BufferedImage method, it didn’t work that well. And yeah I’m creating a different image each time, I’m randomizing the colours in fact, and moving the box across the screen, as well as using translucency, and the framerate is staying above 70. That’s without adding any optimizations too.

When I referred to “graphics subsystem”, I was referring to MY graphics subsystem, a simple little thing that allows you to attach objects implementing the interface “Renderable” and have them automatically drawn each frame.

The way I’m doing my pixel plot is I wrapped my VolatileImage and MemoryImageSource into a class. You can query the class for the Graphics2D object of course. It also supplies pixel setting functions, which manipulate a local array, then let you use “copyPixels()” to throw all the pixels currently in the array into the VolatileImage backbuffer.

It’s working great, much better than BufferedImage did, even when I tried grabbing the WritableRaster and throwing a block of pixels into the Image in one go.

BTW. I do believe it’s spelt “analphabetic” ::slight_smile:

#15

as well as using translucency, and the framerate is staying above 70. That’s without adding any optimizations too.
So not 200fps :wink:
I get 85fps on my rather underpowered laptop (in terms of graphic-chipset) when using the OpenGL pipeline. (Its a GF2-class chipset) using the bufferedimage-approach.

For what you are using MemoryImageSurface it wasn’t designed for, its almost the same as using PixelGrabber for periodically get the pixels of an VolatileImage. It works find for now, if you’ve look it will too on newer pipelines or not - not. Well it leaves me … cold?

lg Clemens

#16

I never specifially asked for your attention, though I am appreciative. What I don’t appreciate is you trying to soudn superior using big words and sounding all tough.

And whether or not the new image data is being changed in one thread or the other, the new image data is just that, new image data. It’s NEW. Meaning it hasn’t been cached. So yes, I’m blitting a new Image every frame.

Maybe I’ll give the BufferedImage another go, I’m having slight problems with the MemoryImageSource, namely, I can’t clear the array very fast, 'cos Images created with an ImageProducer don’t allow you to use a Graphics object with them.

#17

Well, I tried BufferedImage again, 50fps drop in speed, from 80fps to 30fps.

It’s using the same system my MemoryImageSouce code is using too, I just substituted the MemoryImageSource and it’s corresponding image with a bufferedimage.

#18

well thats right so I actually wont waste my time anymore :wink:

#19

Alright… I forgot your time was so much more important than mine! :o

#20

Seems the original question has been answered and the conversation is going down hill.

LOCKED.

Kev