What is the fastest way of setting screen pixels?

Performance Tuning
#1

Hiya, sorry for the newbie question, but I couldn’t find a good answer for this anywhere.

Basically I want to try to experiment a bit with building my own tiny (realtime) 3D rendering engine in java. I’d like to have a screen, then want to calculate a color for every pixel, and drop them on the screen.

It’s the last part, just putting the pixels on screen, that’s giving me some trouble. Methods like .drawRect() or .drawLine() on graphics objects for one pixel just feel way to slow. Even just iterating over all pixels and setting them to one color is way too slow. I’m looking for the fastest way of doing it, with as low of a level as necessary. Manipulating a large byte array representing colors for example would be great if that’s the fastest way of doing it. The only requirement besides speed is that it must allow me to calculate the pixels myself (so no libraries that have you send models/polygons over)

I don’t particularly care what the pixels are drawn on, as long as whoever is using the program can actually see what I’m drawing in real time. Small bonus points are given if it also works on Android (with minor modifications), but it’s really speed that’s most important to me here.

Of course the speed would be much higher if I can offload calculations to the GPU, so ideally this method allows me to use one.

What are my options here?

#2

Since you are explicitly striving for performance and seemingly not for the “joy of building a rasterizer” you’ve basically presented the only viable solution/answer yourself:
OpenGL (on Android: “OpenGL for Embedded Systems”).

[quote]I’m looking for the fastest way of doing it, with as low of a level as necessary
[/quote]
=> OpenGL or Vulkan (but for simplicity I suggest OpenGL)

[quote]The only requirement besides speed is that it must allow me to calculate the pixels myself (so no libraries that have you send models/polygons over)
[/quote]
=> Shaders in OpenGL

[quote]Small bonus points are given if it also works on Android (with minor modifications)
[/quote]
=> OpenGL ES

[quote]but it’s really speed that’s most important to me here
[/quote]
=> OpenGL

[quote]Of course the speed would be much higher if I can offload calculations to the GPU, so ideally this method allows me to use one.
[/quote]
=> OpenGL!

#3

Actually, the joy of building a rasterizer is an essential component which I meant with the ability to set pixels myself / building a rendering engine. Unless I’m mistaken about OpenGL, it’s basically doing exactly the same thing as what I’d like to build myself here, which kind of defeats the point.

The speed is important to me because I’d like to see how fast of a rendering engine I can build in Java. While obviously there’s no way to compete with OpenGL because we’re sitting in the JVM, it feels kind of dumb to have an instant dramatic performance hit just for putting the pixels on screen.

#4

Check out mine, lol. I did exactly what you’re going for. Avoid using the awt Graphics and only use it to blit a BufferedImage to your frame. Your renderer should literally just set pixels in an array (the buffer in the BufferedImage).

#5

[quote]OpenGL, it’s basically doing exactly the same thing as what I’d like to build myself
[/quote]
OpenGL can do what you’re trying to do; e.g., given some world representation, convert them to screen pixels. But it’s really up to u how u decide to use openGl. You could totally give openGl a 1d or 2d array of pixel colors, and have openGl draw them on screen.

I’ve built some projects that did the conversion from 3D world representation to 2D screen uniform-color quads/triangles, and then let openGl take care of those (because it’s faster than Java2D). So it’s really up to u how much of you’re logic you want to do “reinvent” and how much you want to use openGl to do.

Side note, openGl doesn’t really “do things for you”, it’s a library/framework that provides you with the tools that make it easier and simpler to do yourself. You’re still multiplying model matrices with your vertexes and such. I wouldn’t call it an “engine.”

#6

Hi

You can use JOGL as it supports both desktop and embedded environments, it exposes both OpenGL and OpenGL-ES APIs. You can make your own rasterizer and simply call glDrawPixels to draw the result:
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glDrawPixels.xml

However, glDrawPixels is only in OpenGL (backward compatible context), not in OpenGL ES. You could use a FBO instead.

#7

Yeah that sounds like exactly the thing I’m looking for. I couldn’t find the relevant part of the source on your page though

And thanks buddyBro and gouessej, that does make OpenGL sound like it could do what I’m looking for. I’ll try exploring it and see if just sending pixels there works better than the alternatives

Edit:
Alright, I’m satisfied, thanks for your help! I’m now using the LWJGL library to bind to OpenGL, and it has a glDrawPixels method that just takes a pixel array, this allows ~800 fps on my machine on a baseline test where I don’t change any pixels. This is more than plenty to experiment with