Lets have a little chalenge here ok ?
The chalenge is to make the fastest static method wose semantics is just draw a single pixel using the interface:
Graphics.drawPixel(Component c, int x, int y, int color);
Whats your best shot.
;D
PS: The semantics of the method doesn’t say the pixel must be drawn immideatly and that no other methods can be used to complement the operation.
Write your own software renderer, then the drawPixel becomes a multiply, an add, and a write into an array.
Don’t you have a more easy solution ? ;D
How would you put that array on screen without suffering a huge performance penality ?
Theres a load of stuff including some sample code here:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1073992902;start=5#5
And:
Hope this helps,
ok thanks
well back for another round with java sdl ;D
thanks for all the info but what is for now the fast ways to draw pixels. I do not think 1mio drawLines would be more optimal that Imageproducer.
Are BufferedImage typically faster than those old 1.1 (ImageProducer) apis?
The question why I am asking is the fact that I am realizing a software renderer which has serious problems with iamge-rendering throughput.
lg Clemens
The fastest way to draw a pixel should be like that:
Create an BufferedImage and specify the format.
If you’ve chosen TYPE_3BYTE_BGR you can get the data array and set the values to your color value. Something like:
byte[] data=((DataBufferByte)img.getRaster().getDataBuffer()).getData();
(There’s a bit in the FAQ about that: Then take a look at the FAQ on http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1097853220 )
I get a 5-10 fps increase with my software renderer if I switch from the Producer/Consumer model to the BufferedImage Model (compiled with 1.5). Do note though that getting direct access to the pixels stops any possibility of hardware acceleration. Too bad because I seem to always want access to it in my games. The speed increase seems to be mainly from avoiding that nasty newPixels call although I could be wrong. I tried implementing my own producer, but didn’t notice a difference from the MemoryImageSource so I currently use that for my 1.1 needs. Anyway, on a 2Ghz system I can easily get 60fps at 500x500 for a fully textured 3D world using a producer and it’s not even close to fully optimized so the throughput should be fine for most applications.
Why waste time developing a software renderer?
They are only useful in Applets, and as webstart is a far superior alternative in most cases, Applets in my view are an obsolete technoogy.
The sooner people stop using them, the better.
Hmm, maybe you want to do something that can not be done in Hardware?
Think of Voxel engines for example, I like voxel engines very much, cause they look much more natural than texture stuff does…
however, everybody should use what he wants to!
I think I saw a recent demo of a voxel engine implemented in OpenGL shaders on opengl.org…
Back to the original question:
fastest way to draw a pixel is as Dom says to supply your own Graphics implementation and write directly into a nice simple array, and when you’re all done with that array, blit the whole thing straight to the screen front buffer with one call.
Cas
[quote]Why waste time developing a software renderer?
[/quote]
People are using software renderers for various reasons: no hardware acceleration available, no OpenGL binding, old VMs, rendering takes places on a web server, etc. jPCT can do both, software and hardware, and people are still using the software renderer most of the time. So there definitly is a “market” for software rendering…just maybe not that much in this community, which covers a very tiny niche only.
And arguing that way, almost everything that we’re doing here is a waste of time. Who cares for the 1000000th clone of tron or tetris written in Java except for the proud author?
[quote]Why waste time developing a software renderer?
[/quote]
Its a good way to learn. Its fun. Its interesting. etc…
This is getting off topic and this particular off topic has been discussed in extreme depth several times on this board (I can think of 3 right now).
Keep in mind that the question “what is the fastest way to draw a (single) pixel” has little or mno relevance to the question “what is the fastest way to draw N pixeles, where N is at all significant in size.”
Bsaically, this is the same old (everyone say it with me) microbenchmarking fallacy.
To draw a whole bunch of unique pixels to a fast frame buffer with no applicable hardware assist its likely for instance that simple mapping the frame buffer using NIO and using the main processor will be a good candidate. OTOH for a single pixel the over-head in setting it up might not be worth it.
Similarly the architecture of your platform and its capabilities will have a big impact on the answer to this question.
In that regard, I think the fault is with the question =)
Does zingbat realy want to modify just 1 pixel, or does he want to know the fastest way to manipulate many pixels, each individually.
The question is exactly the question i wanted to make. The fastest way to draw a pixel. This means im stuck with an atomic operation like DrawPixel(x,y).
So this was a hypothetical, not practical question?
[quote]So this was a hypothetical, not practical question?
[/quote]
Yes.
g.fillRect(x,y,0,0); 
[quote]So this was a hypothetical, not practical question?
[/quote]
It was a pratical question but in the sense of having restrictions that aren’t pratical. ;D
Like the use of the DrawPixel method that is required for the implemention of classic algorithms like drawLine or fillPolygon.