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



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);
    point(pos.x, pos.y);
    fill(155, 0, 0);
    float tmp2 = map(pos.x, 0, width, 5, 20);
    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.
accepts floats but also state that textSize is in units of pixels so casting to an int would provide pixel sizes.



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…