# Framerate going down unexpectedly

**URL:** <https://discourse.processing.org/t/framerate-going-down-unexpectedly/16400>\
**Category:** Processing\
**Created:** [December 14, 2019, 5:20pm UTC](https://discourse.processing.org/t/framerate-going-down-unexpectedly/16400 "2019-12-14T17:20:13Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![pieter123](https://avatars.discourse-cdn.com/v4/letter/p/a8b319/32.png) [@pieter123](https://discourse.processing.org/u/pieter123)\
**Post date:** [December 14, 2019, 5:20pm UTC](https://discourse.processing.org/t/framerate-going-down-unexpectedly/16400/1 "2019-12-14T17:20:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![glv](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/glv/32/18785_2.png) [@glv](https://discourse.processing.org/u/glv)\
**Post date:** [December 14, 2019, 6:16pm UTC](https://discourse.processing.org/t/framerate-going-down-unexpectedly/16400/2 "2019-12-14T18:16:31Z")

</div>

Hello,

I tried it with this:

> **[daneden/processing-flow-field](https://github.com/daneden/processing-flow-field)**
>
> Contribute to daneden/processing-flow-field development by creating an account on GitHub.

And modified:

```auto
int noOfPoints = 250;

```

```auto
void draw() {
  surface.setTitle("FrameRate: " + frameRate); //Set the frame title to the frame rate`

```

```auto
  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.

 ![image](https://canada1.discourse-cdn.com/flex036/uploads/processingfoundation1/original/2X/b/bc2e77f182ccf659cc0604b3f6793d3eccde3ad0.jpeg)

[https://processing.org/reference/textSize\_.html](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.

🙂

---

<div class="post-metadata">

**Author:** ![pieter123](https://avatars.discourse-cdn.com/v4/letter/p/a8b319/32.png) [@pieter123](https://discourse.processing.org/u/pieter123)\
**Post date:** [December 15, 2019, 10:15am UTC](https://discourse.processing.org/t/framerate-going-down-unexpectedly/16400/3 "2019-12-15T10:15:08Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![jeremydouglass](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/jeremydouglass/32/20_2.png) [@jeremydouglass](https://discourse.processing.org/u/jeremydouglass)\
**Post date:** [December 17, 2019, 6:13am UTC](https://discourse.processing.org/t/framerate-going-down-unexpectedly/16400/4 "2019-12-17T06:13:53Z")

</div>

> [@pieter123](#):
>
> it causes a huge memory leak

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