In the following example there is a stripped down version of everything I do in processing or have been doing since 2009, things moving across the screen at equal speed.
All this time I have never seen a movement like this look completely smooth on any system except maybe once in a mega gaming computer with top specs. That inspired me to purchase an eGPU a Nvidia GTX-1080 which is very good off course but this only helps a little bit.
I wonder if there is anything I can do to make continuous movements look smoother and less choppy. Is there something I can do to code this type of thing more efficiently and/or is there a way to utilize better my fancy eGPU. I have tried the P2D renderer and the results are not much different.
Do I just need to get the fanciest CPU available? What puzzles me is that it seems like a simple task. It seems to be easy to make much more complicated things look smooth and easy.
Donāt worry, you donāt need the fanciest CPU available for tasks like these
The choppy/jittery motion is likely a result of the way you coded your sketch. At a default frameRate of 60, youāre asking Processing to recalculate positions and sizes for 5 rectangles 60 times a second. Additionally all rectangles will be āredrawn from scratchā at each frame.
Seeing the sizes of the shapes stay the same throughout your sketch, you could already improve your code by using PShapes. It enables you to store a shape as data which you can then reuse throughout your sketch, meaning your sketch wonāt have to redraw it from scratch 60 times a second any more. Now it only has to recalculate the positions and place the existing shapes.
The PShape tutorial contains more examples and explanation. Another thing you can look into are classes, but for the example you showed us PShapes will probably suffice.
The P2D renderer, if not the default renderer, is likely to be locked to the vsync of the display. Itās worth trying a framerate at least as high as the display refresh rate, although potentially better set to 2x or more (eg. 120 for a 60Hz display). Of course, if your display is something like 75Hz then 30 or 60 fps will be jerky.
The other thing is that you might be better moving the rectangles based on time rather than a fixed amount per frame.
it helps to show the FPS
and to play with / compare modes: size(640, 360); // ,FX2D P2D P3D
( using low end hardware i found size(640, 360); most choppy )
Iāve been testing all of these things. Iām sure the PShape thing will be very helpful in my final result which has a lot of stuff, Iām already implementing it.
So I did try 120 fps and 60 30 and yes the screen Iām using is 60hz and yes, I have experienced phasing before. I had never tried the FX2D before, I ddināt know about it, itās much better actually, works really well with my setup apparently. Iām continuing to try this all out.
So Iām changing sizes and doing fps monitoring and even when itās flatlined I still see the occasional jump/jitter although much much less than before.
So there is yet something other that is interrupting as well, which is not framerate or refresh rate related apparently. Some programmer who is not familiar with processing told me about hardware affinity or thread affinity, wondering if dual or multiple core processors etc, actually might cause such glitches in real-time renderings when things are being sent back and forth, while creating a hardware affinity you can link the whole code to one core or thread in the CPU. I wonder if anyone has experience with this or if it is at all possible in processing and if itās even feasible at all.
And then maybe Iām just paranoid by looking at the screen for to long, seeing jitters everywhere I look.
Ah, I have a mac with an eGPU and cannot seem to access these parameters. But they might be setup already. Iāll look into how to find them. Even if via terminal or whatever. It might change something.