Improving Efficiency

johnjjr

in Processing with Other Languages • 2 years ago

Hello,

I am working with a group that has been tasked with drawing a large number of objects that are drawn to the Canvas.

We currently have the fps set to 30.

Inside the draw function we loop through an array of 250 objects and draw each one based on a dynamically changing set of x,y coordinates.

Processing.js has slowed down to about 12 fps at this point. We are actually looking for a solution to render/animate up to animate up to 1,000 nodes.

We are currently just starting to study ways in which processing.Js can be made more efficient. We have tried engaging the GPU by adding a third parameter to the size function (..., P3D), but this actually slows down the fps.

Any ideas or suggestions would be greatly appreciated.

Replies(4)

jobleonard

Re: Improving Efficiency

2 years ago

Some more information is needed to really help. As what are the objects being drawn? Points? Shapes? Images?

I only have one suggestion now, and it's unlikely to make a big difference.

Instead of an array of 250 objects, each storing an x and y coordinate, try making an object with an x and y array of 250 points long. So instead of something like:

Whatever[] initWhatever(int s)
Whatever[] tmp = new Whatever[s];
// do whatever is needed to init the array
return tmp;
}
class Whatever {
int x, y;
// other variables and functions
}

do:

class Whatevers{
int[] x, y
// other variables, transformed into arrays as well
Whatever(int s){
x = new int[s];
y = new int[s];
// other initialisation
}
void updateAndDraw(){
for (int i = 0; i < x.length; ++i){
// updateAndDraw stuff
}
}
}

If all coordinates stored sequentially in memory, memory lookup might decrease because of something to do with cpu-cache. It also reduced the amount of dereferencing required.

HOWEVER, I have no idea if the former also applies to pjs, and how big of an influence the optimisation has as a whole (again, because it's not clear where the bottleneck is).

EDIT: On top of that, if you use ints instead of floats for the coordinates and you know the coordinates will be limited to values between 0 and 32767 (or 15 bits), you can fit an (x,y) coordinate in one int (which is 32 bits, but uses one bit for the sign) with bit-shifting and bit masking:

int x, y, xy;
//convert an x and y to xy
int xy = ( ( x & 32767 ) << 15 ) + ( y & 32767 );
//extract x and/or y from xy
y = xy & 32767;
x = ( ( xy >> 15 ) & 32767 );

This works because looking up values from memory tends to be more expensive than CPU cycles. Again, no idea if this actually holds true for Javascript, and depending on where and how you convert these values it might even be slower. It does save up one int of memory per coordinate though ;). Woohoo! 500 bytes baby! Minus the extra lines of code..

Jo Wood

Re: Improving Efficiency

2 years ago

It's worth finding out where the bottleneck is that is slowing down the frame rate. Is it the drawing, or the gathering of the realtime data?

Some tricks to speed up the drawing could include only updating a fraction of the objects (say, half of them) on each draw cycle. This can still give the impression of movement, but at less cost.

Do some of the objects not change between update cycles? If so, and there is a significant number of them that don't change for several cycles, they could be rendered to an image and that image displayed, only displaying the moving objects on top of that. It all depends on the nature of the process you are representing and how easy it is to identify the static objects. Drawing solid objects with both a fill and an edge can be costly. Can you get away with a noStroke() and just fill for example? This could speed things up.

If the bottleneck is the harvesting of your realtime updates, consider doing this in a separate thread (if you are not already), so that drawing is not waiting for an update.

Personally, I think these types of changes are more likely to yield apparent performance increases that trying to second guess how internal memory is managed (which itself may vary from machine to machine depending on the OS and JavaScript engine).

PhiLho

Re: Improving Efficiency

2 years ago

Moved to Processing Implementations, as you have nothing to exhibit.

And, sorry jobleonard, but I doubt your tricks, however smart they are, will save much CPU. Particularly the second one. " looking up values from memory tends to be more expensive than CPU cycles" This has to be proven!
Like all optimizations, you don't have to do guesses, but to do measures. Ideally with a profiler, although I don't know one in browsers...
Your tricks reduce readability and maintenability, which is a major sin if the "improvements" aren't noticeable (but acceptable if they really speed up the sketch, which I doubt. At best they save a little bit of memory, which is negligible).

jeff_g

Re: Improving Efficiency

2 years ago

I'm not sure if Processing.js supports it through WebGL, but a VBO would be a fast way to do it and then just update the positions in one array buffer. That should easily animate 1000 nodes.

Top Reply