fix point() origin bug and stale per-vertex color leak

[perminder-17]

Resolves #8701

In _drawPoints, we now sync incoming vertices into this.immediateMode.geometry.vertices before _prepareBuffer runs. This ensures aPosition gets real point coordinates instead of falling back to (0,0,0).

Color leak fix:
For direct point() calls, we clear stale vertexStrokeColors (left over from beginShape(POINTS)). This makes point() use current stroke() color while beginShape(POINTS) still uses per-vertex colors correctly.

PR Checklist

• npm run lint passes
• Inline reference is included / updated
• Unit tests are included / updated

[perminder-17]

https://editor.p5js.org/aman12345/sketches/FzSrg-6pj

here's the build.

[ksen0]

I tried it out, also with some push/pops on color. It seems to function for me; the PR fixes the regression, but does not add parity for the weight effect, which is also mentioned in the issue. I checked earlier 1.x versions, and the behavior is indeed different between 1.x and 2.x - @davepagurek note the strokeWeight(8); which is definitely doing something in both cases, but a different thing. However as this is not a regression, I do not think it should be touched in this PR, though documenting why there's a difference would be good if it's intentional.

[davepagurek]

In 2.x points have the same width as strokes, whereas in 1.x I believe they are using half the width? e.g. if I draw a line in the background, in the build above it looks like this:

function setup() {
  createCanvas(600, 600, WEBGL);
// }

  // strokeWeight(80)
// function draw() {
  background(0);
//  camera(0, 0, 300, 0, 0, 0, 0, 1, 0);

  strokeWeight(80);
  
  stroke('white')
  line(-width/2, -height/2, width/2, height/2)

  // Per-vertex stroke colors using beginShape(POINTS)
  beginShape(POINTS);

  stroke(255, 0, 0);     // Red
  vertex(-60, -40, 0);

  stroke(0, 255, 0);     // Green
  vertex(-20, -40, 0);

  stroke(0, 0, 255);     // Blue
  vertex(20, -40, 0);

  stroke(255, 255, 0);   // Yellow
  vertex(60, -40, 0);

  endShape();

  // Single point() calls for comparison
  stroke(255, 0, 255);   // Magenta
  point(-40, 40, 0);
// push()
// translate(-40, 0, 0);
  stroke(0, 255, 255);   // Cyan
  point(0, 30, 0);
  // pop()


  stroke(255, 0, 255);           // White
  point(40, 40, 0);
}

This PR	2.x

Note that I also commented out the camera call. Further complicating things is that in 1.x the point radius did not scale with the camera, so if you uncomment the camera call, you get:

This PR	2.x

So basically 2.x handles points a lot more consistently with strokes (by actually removing the separate render path for points and turning them into strokes behind the scenes.)

[davepagurek]

Agreed that it's not worth refactoring to fully match 2.x -- it's a pretty big/risky change to do that in 1.x at this point, and I wouldn't be surprised if some 1.x sketches depend on this behaviour and would break if we change it, even though the new behaviour is more consistent overall.

[ksen0]

Agreed that it's not worth refactoring to fully match 2.x -- it's a pretty big/risky change to do that in 1.x at this point, and I wouldn't be surprised if some 1.x sketches depend on this behaviour and would break if we change it, even though the new behaviour is more consistent overall.

Agreed. And thanks for the illustrations, @perminder-17 I think it'd be great to add those illustrations to the compatibility repo

[perminder-17]

Agreed. And thanks for the illustrations, @perminder-17 I think it'd be great to add those illustrations to the compatibility repo

Sure, Thanks @davepagurek for the examples.

[davepagurek]

Thanks for working on a fix @perminder-17!

[perminder-17]

Thanks for working on a fix @perminder-17!

Yeah, happy to help!