Changing Stroke Mid-Curve Drawing Changes Entire Curve Colour

[SethGreylyn]

Nature of issue?

• Found a bug

Most appropriate sub-area of p5.js?

• Color
• Shape

Which platform were you using when you encountered this?

• Desktop/Laptop

Details about the bug:

I've been following the Coding Challenge videos, recreating the most interesting ones in P5; tonight I recreated the Lorenz Attractor, and I discovered that changing 'stroke' while adding curveVertex() to a shape causes the entire curve to be coloured with the stroke's argument (i.e., instead of drawing a rainbow, the whole curve changes from one solid colour to another).

• p5.js version: https://cdnjs.cloudflare.com/ajax/libs/p5.js/0.5.16/p5.js
• Web browser and version: Chrome 61.0.3163.100
• Operating System: Windows 10
• Steps to reproduce this:

The code I'm playing with is here, and the code in question is

translate(width / 2, height / 2);
scale(5);
noFill();
beginShape(points);

var rSeed = 50;
var gSeed = 100;
var bSeed = 198;

points.forEach((pnt) => {
print(rSeed, gSeed, bSeed);
stroke((rSeed++)%256, (gSeed++)%256, (bSeed++)%256);
curveVertex(pnt.x,pnt.y);
});
endShape();

Changing 'curveVertex()' to 'point()' results in differently-coloured points, so the basic logic is correct. (It also matches the Java logic in the Lorenz video.)

[Zalastax]

I agree that it seems weird, but it's apparently expected behaviour. Quouting @zaerl:

The curveVertex function collects vertices. Once it has 4 vertices the curve function is called which actually draw at screen the curve (with a beginShape - > endShape -> closePath -> stroke calls chain).

I don't know if this should be considered a documentation issue, bug, or maybe even a new feature request. For the end user it sure is annoying so I think some solution should be provided, be it an example or new functions.

[SethGreylyn]

Thanks for looking into it! It seems to be a feature parity issue, since the logic is the same as in Processing, but the behaviour is different. (Using 'vertex()', which matches the method name in Processing, does not change the behaviour of P5 noticeably.)

I assume 100% feature parity was not the goal of P5.js, so perhaps it should documented.

[Spongman]

the weird thing is that Processing isn't itself consistent. the canvas renderer uses whatever the state is when the endShape call is made. however, the P3D renderer allows you to change vertex colors, line thicknesses, etc... between each vertex call.

[lmccart]

Yeah, I believe this is correct behavior but the documentation could add a note about this. Processing parity is not a goal here, so we're free to design this library as we'd like.

[brymer-meneses]

Any update on this issue?

[davepagurek]

This is now resolved in 2.0 after #7373!