Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frame rate slows to a crawl when calling text() #69

Closed
martinmaxk opened this issue Aug 29, 2018 · 4 comments · May be fixed by #73
Closed

Frame rate slows to a crawl when calling text() #69

martinmaxk opened this issue Aug 29, 2018 · 4 comments · May be fixed by #73

Comments

@martinmaxk
Copy link

martinmaxk commented Aug 29, 2018

Describe the bug
When drawing text on screen (calling text() from draw() ) the FPS drops to 2

To Reproduce

from p5 import *

def setup():
    size(800, 800)
    no_stroke()

def draw():
    text("Test", (26, 30))
    print(frame_rate)

run()

Expected behavior
Should print 50-60

System information:

  • p5 release (version number or latest commit): Not sure, I downloaded it with pip a couple of days ago
  • Python version: 3.6.5
  • Operating system: Windows 10
@abhikpal
Copy link
Member

abhikpal commented Sep 2, 2018

As of now, most of typography-related methods are just prototypes. We added them when we were done with our other Google Summer of Code goals. We do intend to optimize this later.

@MrGallo
Copy link

MrGallo commented Oct 3, 2018

I don't have much experience with optimizing things like this, but, I managed to trace the source of the slowdown:

data = np.array(self._img.getdata(), dtype=np.uint8)

Perhaps my observations are obvious to the authors:

  1. We can speed up the time it takes np.array() to run by passing it the PIL.Image object rather than PIL.Image.getdata(). Like so:
    data = np.array(self._img, dtype=np.uint8)
    This really only got me from 1.7fps to 14fps on my computer. (640x480 canvas)
  2. It might be beneficial if the PIL.Image object's size was constrained to the size of the actual text being printed, rather than the whole canvas size.

Again, I don't really know the fine details of what's going on. I thought I would just point this out.

@abhikpal
Copy link
Member

abhikpal commented Oct 7, 2018

@MrGallo, you're correct. I didn't look into this much, but your comments do seem reasonable. I don't have the time to work on this right now, but I'll be happy to accept pull requests that implement this change. I'm also assuming that I'm calling PIL.Image.getdata() in other places as well, and that can be fixed too.

It might be beneficial if the PIL.Image object's size was constrained to the size of the actual text being printed, rather than the whole canvas size.

You're correct. Since we were just adding experimental support for text, I didn't spend much time on figuring out the math that gives us a tighter bounding box for the text. Using the whole canvas is really an overkill. Again, happy to accept pull requests :)

This was referenced Oct 25, 2018
@abhikpal
Copy link
Member

This will also be addressed for this year's GSOC (see #104). Might make sense to discuss this there. I'm closing this thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants