hello! i’ve a serious question about performance. In resume, ive a processing sketch that allows me to add 3D geometry in real time, with a few PApplet controller-windows. Also, this gometry is drawing in a PGraphics and send it to a multipass shader system, about 8 multipasses. Now i need to proyect that sketch in a fullHD proyector (1920, 1080) i been working on 1280-720, and frameRate downs from 50 to 30 when i draw about 20 spheres (25 of detail, and 20 of size). But when i set the PGraphics object on 1920-1080 and so the output the frameRate downs considerably. I found a temporary solution using scale(1.5); and leave PGraphics in 1280-720. Here the frameRate downs but not so much. I`ve multiply questions, and i know that with out code is difficult to help, but in general terms:
How can i test the performance? how can i know how much geometry the system soport? assuming that the system works fine, only geometry. im on a macosX el capitan, Intel iris pro 1536mb corei7 2,2gHz. what can i expected?
is something i need to know to get a better perfomance? i mean, working with GLSL, PGraphics objects? ArrayLists consume more memory, and fill() too… for example, it seems that PShape obj downs performance, even if the geometry is the same . … or when the camera is close to geometry the frameRate downs, but if i move away not.
exist an alternative to PGraphics? maybe i need to think about pure Java and not processing? anyone has experience?
is the temporary solution of scale(); good? what you do ?
The scale option is probably what I’d do - well use smaller PGraphics and the scaling version of image().
Are you drawing the spheres with strokes? Are you using strokeWeight? Drawing strokes has a massive performance impact in my experience. (Although mostly about 2D, this issue might have some relevance here - https://github.com/processing/processing/issues/5256)
Are you setting frameRate()? You might try setting that higher - 120, 240, etc. Due to the way that the JOGL timer interacts with vsync this sometimes seems to give better results.
What do you mean by pure Java? You need a library at some level to interact with the GPU. If you’re wanting to do low-level OpenGL there’s always beginPGL(). In terms of other higher-level libraries, there’s things like libGDX (mentioned in the above issue) that can perform better than Processing in some cases (my first PraxisLIVE renderer was based on libGDX).
Have you tried a version without the controller windows running? Have noticed some interactions that can slow down rendering, particularly on macOS, with multiple windows.
The Intel card GPUs are a lot better than they used to be, but they’re still low power. Multiple FHD shaders passes might be stretching it. I think one of the bottlenecks on these is memory bandwidth, which might come into play here. Are you sure it’s the geometry that’s the issue here? What do the shaders do?
Thanks! what do you think about LWJGL?
No, i dont drawing any stroke. The shaders are very simples. Not much of nothing. I discovered that whit less PGRAphics objects performance is a lot better. Exist an alternative way or better way to use multipass shaders wittout PGraphics obj? always read about how processing is not the best way to implement shaders. In that case i`ll investigate about LWJGL. but all my system is in java( is just a particle System, like nature of code style). is possible combine both lenguajes?
They are the same language! I only ever use the Processing libraries from Java too. There is no speed difference just from that change.
It comes down to LWJGL vs JOGL really. I’ve seen an LWJGL backend for Processing. In fact, it was almost the Processing 3 default, and may still be coming. Still, while there are good reasons to switch because JOGL development has stalled, there’s unlikely much speed difference in communicating with the GPU.
As for Processing not being good for shaders, I’d love to read the reasoning on that! Shaders run on the GPU - there’s little reason why Processing vs Java vs C would be any different there.
Do try and keep the number of PGraphics down by reusing them. Without seeing your code I can’t really say more than that though.