WEBGL became extremely slow since p5.js version 1.0.0

[peeter2]

Most appropriate sub-area of p5.js?

• [ ] Accessibility
• [ ] Color
• [X] Core/Environment/Rendering
• [ ] Data
• [ ] DOM
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [X] WebGL
• [ ] Build Process
• [ ] Unit Testing
• [ ] Internalization
• [ ] Friendly Errors
• [ ] Other (specify if possible)

p5.js version

No response

Web browser and version

No response

Operating System

No response

Steps to reproduce this

Steps:

1. Create a speed test using WEBGL, for example here I created random triangles moving around: https://editor.p5js.org/shangtsung/sketches/qMZ_4M4c6
2. You can see that the shapes move around really slow, the whole browser window becomes very slow. Until I remove the 'WEBGL' from createCanvas(800, 600, WEBGL), then everything moves very fast.
3. Also everything moves very fast (including when WEBGL is included) in older p5.js versions before 1.0.0.

So something was messed up in p5.js since version 1.0.0 (including the latest version) that made it very slow.

Or am I missing something?

Probably I was missing this library? https://github.com/davepagurek/p5.buildgeometry

It seems to make this too complicated. Should I switch back to the very old but fast p5.js version or how exactly should I edit my code to make it fast using the latest p5.js?

[davepagurek]

I'll reply with some more suggestions later, but for some context, see this related issue: https://github.com/processing/p5.js/issues/6407

[davepagurek]

Ok here's some more detailed info! I think the two changes that are affecting your benchmark are:

• The default shape mode is now TESS instead of TRIANGLES, which tesselates arbitrary shapes into triangles. This increases shape drawing compatibility with 2D mode, but since you're just drawing triangles anyway, there's extra overhead. For now, calling beginShape(TRIANGLES) will speed up your sketch a lot. I've added an issue here https://github.com/processing/p5.js/issues/6440 to do this automatically if you are drawing triangles.
• Lines are now higher fidelity and support stroke caps and joins. This makes curve drawing useful in WebGL where before the curve segments were visibly discontinuous. Unfortunately it also makes line drawing heavier by default. For cases like yours, consider using noStroke(), or using triangle(...), which caches strokes in retained geometry buffers.
  • Retained geometry means the GPU keeps the shape information and doesn't need to remake it for subsequent draws. In general, any shape that you only move rigidly will perform faster if you use retained geometry. The buildGeometry library is the current way to do that; in the main branch (coming next release!) is an easier-to-use, built-in version of this.

[peeter2]

Thanks for your reply. Although, I already am using noStroke() And adding TRIANGLES to beginShape(TRIANGLES) did not make it any faster either.

[davepagurek]

For what it's worth, on a 2015 Intel Macbook Pro in Chrome, I get the following frame rates:

Browser	0.9.0	1.7.0	1.7.0 + TRIANGLES mode
Chrome	8fps	25fps	35fps
Firefox	30fps	25fps	35fps

I'm not sure why the Chrome one has such a low frame rate for me on the old p5 version, but it is consistent across my tests. All that to say, TRIANGLES seems to make the difference on this machine at least. What browser/OS/hardware do you use?

[peeter2]

Interesting. I am using 2017 Surface Pro, Windows 10. Checked on latest versions of Chrome and Firefox. beginShape(TRIANGLES) did not make a difference for my eyes.

[davepagurek]

If you have the time, if you use your browser's profiler to record a second or two of the sketch running, export the profile as JSON and attach it to a comment, I can take a look and see if anything stands out as abnormal or the cause of the slowdown.

[peeter2]

For sure. Here you are, here it is on Chrome, Surface Pro: https://drive.google.com/file/d/10rvwzm9lgX8SgF1cSsQg0qtn4sfJJwLz/view?usp=sharing On Firefox it is just as slow.

However, I just checked on Edge, and it is performing fast there! No matter if I'm using beginShape(TRIANGLES) or just beginShape() it is working fast just fine.

Also I checked on mobile (iPhone XR) on all browsers (Chrome, Safari, Firefox) and I saw that it is working FAST on that device too! Also doesn't matter whether I'm using beginShape(TRIANGLES) or just beginShape()

So what is wrong with Chrome and Firefox on Surface Pro? Or what is wrong with p5.js? On older versions of p5.js (before 1.0.0) it had fast performance.

[davepagurek]

This is pretty interesting, there are big gaps between each draw:

If I had to guess, that probably means the GPU is working (which isn't captured by this profiler.) As another test, does it make a difference if you do setAttributes({ antialias: false }) right after createCanvas? We may have turned that on by default at some point, and that operation can be slow on some systems.

If that makes no difference, maybe try doing a profile in chrome://tracing with the Frame Viewer preset, which should capture GPU data, and then send that. Maybe that'll have more clues.

[peeter2]

setAttributes({ antialias: false }) did not make a difference.

And here is the output from chrome://tracing (clicked Record, then visited the sketch and clicked Play for a couple of seconds, and then stopped the recording): https://drive.google.com/file/d/1XPFyYnkPAA3et1id7gSgCJ8-2YWFmANH/view?usp=sharing

I hope that helps(?)

[davepagurek]

Well this confirms at least that it's the GPU work that's the bottleneck (the GPU thread is constantly doing stuff):

...but yeah I guess it doesn't tell us what specifically is different. Did you say that v1.0.0 is the first one where you started seeing this issue? I'm thinking that if we can narrow down the specific release where it starts happening, I can look at what changed and get some more leads to investigate.

[peeter2]

Yes, I have tested three versions prior to version 1.0.0, and the same thing is running fast on those versions (on the same computer and browsers).

[peeter2]

Here is something that might help. I created another speed test sketch that performs really fast on versions older than 1.0.0: https://editor.p5js.org/shangtsung/sketches/j080fh87C

And it is very slow on every newer version starting from version 1.0.0, no matter what browser or device. It is slow even on iPhone! It is very fast on version 0.9.0 for example.

I hope that can help resolve the issue. Otherwise we're just going to have to be stuck at using an old version like 0.9.0.

[davepagurek]

Some other things to try:

Does setAttributes({ perPixelLighting: false, antialias: false }) change anything?

Does adding p5.disableFriendlyErrors = true at the top of your sketch make a difference? (Loading a .min.js build of p5 does this automatically.)

Also, to narrow things down further, have you just tested v0.9.0 and v1.0.0? There's also v0.10.0 and v0.10.2 in the tags on Github, I wonder if any of those are OK in order to reduce the number of commits where a change might have happened.

[limzykenneth]

Just to drop in a suggestion here if we are trying to narrow down where precisely performance drop starts, git bisect is really really good, saved me tons of time before and I highly recommend it.

[peeter2]

Does setAttributes({ perPixelLighting: false, antialias: false }) change anything?

No, this did not make any difference.

Does adding p5.disableFriendlyErrors = true at the top of your sketch make a difference? (Loading a .min.js build of p5 does this automatically.)

I'm not using a minified p5.js in my sketch.

Also, to narrow things down further, have you just tested v0.9.0 and v1.0.0? There's also v0.10.0 and v0.10.2 in the tags on Github, I wonder if any of those are OK in order to reduce the number of commits where a change might have happened.

Yes, I have tested on v0.10.0 and v0.10.2 and they are also fast. Slowness starts from version 1.0.0.

You can see for yourself, simply change the p5.js version in my sketch index.html and see how drastically the performance changes.

[xlinx]

This is pretty interesting, there are big gaps between each draw:

If I had to guess, that probably means the GPU is working (which isn't captured by this profiler.) As another test, does it make a difference if you do setAttributes({ antialias: false }) right after createCanvas? We may have turned that on by default at some point, and that operation can be slow on some systems.

If that makes no difference, maybe try doing a profile in chrome://tracing with the Frame Viewer preset, which should capture GPU data, and then send that. Maybe that'll have more clues.

same issue. FYI. active WEBGL, draw only simple line and simple small image a fix image. performance has gap every 10ms.