Framerate going down unexpectedly

I’m working with particles in a flowfield, based on Shiffman’s tutorial in which a lot of lines, circles and text are drawn to the screen on every draw. Normally this runs very smooth with an fps of 60 or more. However, I noticed that ‘suddenly’ all runs gradually started to slow down within seconds. After a minute they’re all down to 1-2 fps, with memory for the process is 1100+ MB while normally being in the ~400’s.
After a lot of debugging the culprit turned out to be a the text size which was dynamically changed for every particle in every run with a textSize(txtSize). This happened with a particlenumber as low as 250. I’d say Processing should be able to handle this without problems. This is my first post here, but I couldn’t find a similar topic.
Could it be some memory leak or is it a known problem that I wasn’t aware of?

SYSTEM: Processing 3.5.3 on Win10 with 16GB RAM

2 Likes

Hello,

I tried it with this:

And modified:

int noOfPoints = 250;
void draw() {
  surface.setTitle("FrameRate: " + frameRate); //Set the frame title to the frame rate`
  public void show() {
    stroke(255, 50);
    strokeWeight(2);
    point(pos.x, pos.y);
    fill(155, 0, 0);
    float tmp2 = map(pos.x, 0, width, 5, 20);
    //println(pos.x);
    //println(frameRate);
    textSize(int(tmp2));
    text("X", pos.x, pos.y);
  }

I cast the textSize to an int and frame rates were 60 fps.
Otherwise, they slowed down significantly; you can try this.

https://processing.org/reference/textSize_.html
accepts floats but also state that textSize is in units of pixels so casting to an int would provide pixel sizes.

:slight_smile:

3 Likes

thanks, this did the trick! In hindsight actually quite obvious, but well you know how one can get stuck on obvious things.

And still wondering: shouldn’t Processing complain about feeding a textSize() with floats? I’d say it’s still a bug since it causes a huge memory leak…

If this is true and it isn’t yet reported as an issue on GitHub, please do…