Is PGraphics the only way to solve the memory problems in Processing?

General Discussion Other

Nokjao

Is PGraphics the only way to solve the memory problems in Processing?

in General Discussion • Other • 1 year ago

With garbage collector I assume there's no way to allocate computer's memory manually in Processing (or Java). This prevents processing software from running heavy-duty. When dealing with numerous generatively created objects, Processing sketches always slow down to an end (crash). Not to mention if a single object has some elaborate details of its own.

In such case, is designing an object as a seperate PGraphic sprite (say, with transparent background) the only way to deal with this matter?

Replies(11)

PhiLho

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

" I assume there's no way to allocate computer's memory manually in Processing (or Java)"
Not sure what you mean there, but each time you create an object, including arrays, you allocate memory.

" When dealing with numerous generatively created objects, Processing sketches always slow down to an end (crash). Not to mention if a single object has some elaborate details of its own."
Should be very elaborate, then...
You can also tweak the memory settings of Processing.

" is designing an object as a seperate PGraphic sprite (say, with transparent background) the only way to deal with this matter?"
Now, you have lost me. How it can allow to reduce memory usage? It is a convenient way to compose images, but each PGraphics is consuming quite a chunk of memory, so it won't be a solution for memory usage, rather a source of the (potential) problem...

You are a bit too generic (that's why I moved the topic to General Discussion), so it is hard to give a precise answer.

Nokjao

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

Ok, let me put it this way. I have worked with Processing for some times, and many times I have come across the same problem of "memory overload," which is a serious problem when it comes to interaction. I've pasted an example code below. When you run the code, you'll see that each object staggers and doesn't respond well. Any advice on how to improve the staggering? Thanks.

Fur[] balls = new Fur[100];
void setup() {
size(480, 480);
smooth();
colorMode(RGB);
randomSeed(3);
for (int i = 0; i < balls.length; i++) {
float x = random(width);
float y = random(height);
float d = random(10, width/3);
color c = color(random(0, 255), random(40, 255),
random(70, 255), random(30, 100));
balls[i] = new Fur(x, y, d, c);
}
}
void draw() {
background(255);
for (int i = 0; i < balls.length; i++) {
balls[i].display();
balls[i].jitter();
balls[i].scatter();
}
}
//// subclass Fur, which inherits GumBall ////
class Fur extends GumBall {
Fur(float x, float y, float d, color c) {
super(x, y, d, c);
}
void display() {
strokeWeight(d/500);
stroke(alpha(c));
pushMatrix();
translate(x, y);
for (int deg = 0; deg < 360; deg += 3) {
line(0, 0, cos(radians(deg)) * (d/2), sin(radians(deg)) * (d/2));
}
popMatrix();
super.display();
}
}
/////Superclass GumBall/////////
class GumBall {
float x;
float y;
float d;
float homeX;
float homeY;
color c;
float linger = 0.4;
float speed = 3;
GumBall(float xi, float yi, float di, color ci) {
x = homeX = xi;
y = homeY = yi;
d = di;
c = ci;
}
// The methods
void display() {
noStroke();
fill(c);
ellipseMode(CENTER);
ellipse(x, y, d, d);
fill(alpha(c));
// ellipse(x, y, d/75, d/75);
}
void jitter() {
if ((mouseX < x+100) && (mouseX > x-100)) {
if ((mouseY < y+100) && (mouseY > y-100)) {
x += (random(-speed, speed)*5);
y += (random(-speed, speed)*5);
// x += (noise(-speed, speed)*5);
// y += (noise(-speed, speed)*5);
}
}
else {
x += random(-linger, linger);
y += random(-linger, linger);
}
}
void scatter() {
float easing = 0.15;
float targetX = x;
float targetY = y;
if (mousePressed) {
x += (targetX - (random(-d, width+d))) * easing;
y += (targetY - (random(-d, height+d))) * easing;
}
else {
float easingBack = 0.2;
x += random(homeX - x) * easingBack;
y += random(homeY - y) * easingBack;
}
}
}

amnon.owed

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

The thing is it's not about where you draw it (directly or to a PGraphics) but how many times you draw it. Drawing everything on every draw slows down your program. Your example has a frameRate of 3 fps in JAVA2D. Drawing it to a PGraphics once and then displaying the image is faster then re-drawing the whole shape every time. It's like a painter who makes the same painting 1000 times to show it to a 1000 people. You could also just make one painting and shows that to everybody. Making one painting and showing that is what PGraphics can be used for.

If you want a faster painter (with the exact same code) switch to the OPENGL renderer.

Nokjao

Re: Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

@amnon.owned: I think your answer is leading to the light. I knew it was about placing a whole lot of things in draw(). So saying, the solution is to draw to a PGraphics and display it "1000" times, very much like several monitors displaying one same content. However, with that idea wouldn't each object move like each other? (If only one PGraphics object is called)

amnon.owed

Re: Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

That's why you can make the PGraphics at the object level. Each Gumball/Fur object has their own small (not full screen, just as big as you need) transparent PGraphics. So in total you have 100 PGraphics floating around. Just as you mentioned yourself in your opening post, transparent sprites. It's your Fur display method with all the lines that probably causes the slowdown, so draw those to a PGraphics to see how much you can optimize and increase the fps.

As said, just changing the renderer to OPENGL is the alternative to optimizing under JAVA2D.

PhiLho

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

Your sketch runs for some minutes on my computer without crashing. Apparently, it doesn't consume more that 35 KB, which is reasonable.
The staggering is another issue. You started your thread on memory issues...

Nokjao

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

Yes PhiLho, I was "assuming" that staggering is a memory issue. If it was not, then I beg for forgiveness. I never said this code will crash. I said it staggers and react very slowly.

PhiLho

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

Well, I see the word 'crash' in your initial message, that's why I assumed you had an out of memory issue...
Your sketch isn't using up much memory, but Java activity, particularly with Java2D, is always generating lot of objects, behind the scene or directly by your code. So, indeed the garbage collector can do a "stop the world" activity, to clean up unused memory. There are ways to tweak the GC for a more "real time" behavior, but it is a bit delicate.

Nokjao

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

@PhiLho: Your description is a bit advanced for starters like me, however, if GC can be tweaked then it would be very helpful if you can give a simple code on how to do that. Oh, and by "tweaking the GC" being too delicate, you sound as if it's a sort of holy grail. Is it something that should be done? I mean, Java doesn't have a direct mean to manipulate memories like pointers.

I am not all down to the bits and bytes, but I'm willing to improve and learn more. Please shine on.

Nokjao

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

@amnon.owned: OpenGL renderer wouldn't render properly. It helps with the speed, but the visual turns out weird!

PhiLho

Re: Is PGraphics the only way to solve the memory problems in Processing?

1 year ago

Honestly, I don't have much experience with the GC tweaking. Beside, I fear it is mostly adjusted by command line parameters when running a sketch, which are not accessible, except perhaps after exporting it.

Top Reply