RendererGL performance improvement

[stalgiag]

Nature of issue?

• Found a bug
• Existing feature enhancement
• New feature request

Most appropriate sub-area of p5.js?

• Color
• Core/Environment/Rendering
• Data
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Other (specify if possible)

Which platform were you using when you encountered this?

• Mobile/Tablet (touch devices)
• Desktop/Laptop
• Others (specify if possible)

I am working with WebGL mode on Mobile a lot for the first time and I have been forced to recognize how much the performance suffers. I have profiled a lot of our manual test examples and I think there are minor changes throughout the code that could offer some modest performance improvement.

I will propose the changes more specifically here once I get around to this task. If folks have suggestions in the interim they are welcome to post them here.

[aferriss]

I've also noticed that there are a ton of redundant GL calls happening which could be hamstringing performance. It's a bit dated, but this old tool has a nice feature for showing redundant calls.

[mkmori]

Might this include performance related to "lights()" in an offscreen buffer? Apparently, it gives expected results (and more consistent performance) when lights() is only called (once?) in setup() for a given p5.Graphics object...but if called in the draw() loop for the same object, (as done for lights() on the main canvas), it seems like new lights are created each pass (?) and the millis reported in 'requestAnimationFrame handler' "violation" climb while the program runs.

(I'm trying to tease apart various WEBGL issues while investigating why my box() normals appear reversed now in 0.9.0: Have also noticed, I think, red channel-only illumination when using the single variable, color(grayscale) format for lights--thought I saw a possibly related issue re.: color string parsing somewhere....)

Not sure whether to log an issue here...or maybe it's more of a documentation/reference issue...?

(Sorry, I know I'm being a bit lazy here...I will try to post more individual issues time-permitting!)

https://codepen.io/amfm2002/pen/XLBRNK

[stalgiag]

Sorry for the delay @mkmori. Your comment seems to point to something more specific than the topic of this issue. If you would still like help related to graphics buffers and lights() feel free to open a separate issue.

So my primary plan for performance improvement is to cache the current rendering state and only update the uniforms when an actual change has occurred. The RendererGL properties are more than a little all over the place right now, so this might require some shuffling and organizing as well.

This is in part inspired by this discussion in three.js.

[stalgiag]

Bumping this to the 1.0 milestone since it will take a little bit of planning and thought to add cache checks and nicely reorganize RendererGL properties.