Improve performance of line rendering

[davepagurek]

Addresses #5975

While the architectural changes in #6162 might be a bit more difficult to weigh as they are not always better across the board for all browsers, there are some changes that can be pulled out to improve the performance of the existing line rendering architecture without actually changing the way lines are represented.

Changes

• No longer checks the state of backface culling; instead, it makes the vertex ordering consistent so that we don't need to disable culling when drawing lines
• Removes the need for flattening line data before rendering; instead, it is put into the arrays in a pre-flattened state
• Stores line buffer data in a Float32Array from the beginning so that it can be reused without constantly reallocating new arrays
• Changes registerEnabled to a Set (not really a perf update, but makes it easier to loop over enabled registers in the future)

Performance

Test sketch: https://editor.p5js.org/davepagurek/sketches/7jnWpXBq_

Many lines

Browser	1.6.0	This PR
Chrome	60fps	60fps
Firefox	15fps	60fps
Safari	5fps	5fps
Mobile Chrome	6fps	8fps

Large curve

Browser	1.6.0	This PR
Chrome	24fps	28fps
Firefox	11fps	20fps
Safari	20fps	27fps
Mobile Chrome	9fps	14fps

Retained shapes

Browser	1.6.0	This PR
Chrome	60fps	60fps
Firefox	60fps	60fps
Safari	60fps	60fps
Mobile Chrome	60fps	60fps

PR Checklist

• npm run lint passes
• [Inline documentation] is included / updated
• [Unit tests] are included / updated

[aferriss]

I know you're referencing c++ with the vector name, but I feel like within the context of p5 it means something different. Is there a clearer name for this class? DataArray?

[aferriss]

Does this class have use outside of p5 rendering internals? Worth exposing more broadly or at least making a inline doc example for future developers here?

[davepagurek]

I think it's probably only useful for things that need a Flaot32Array, which for now is just rendering. An example for devs can't hurt!

[aferriss]

guessing this is because anything less than a triangle can't have a fill right? Just want to make sure there isn't some weird reason why this was originally set to 1

[davepagurek]

Right! I noticed that in that example where we're drawing a bunch of lines, it was still trying to bind fill buffers. Lines don't have fills, and points are drawn using a separate _drawPoints() method, so I think this should be safe.

[aferriss]

This is awesome! Thanks so much for taking another look at this. I feel much better about these changes knowing it's wins across the board.

Was backface culling actually making a difference? When trying your test sketch I couldn't notice a performance change while turning it on and off.

I left some small comments throughout, but overall I think this is great!

[davepagurek]

Backface culling isn't a performance gain on its own, but since some users turn it on occasionally, we used to have some code to temporarily turn it off and then restore its state when drawing lines. It was that saving/restoring bit that was slow, which is gone now 🙂 The culling toggle in the sketch is to help check that lines don't visually break when culling is turned on.