p5.js icon indicating copy to clipboard operation
p5.js copied to clipboard

Resetting environment variables after each draw call

Open tushar5526 opened this issue 3 years ago • 4 comments
trafficstars

Most appropriate sub-area of p5.js?

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

p5.js version

Latest

Web browser and version

104.0.5112.79 (Official Build) (64-bit)

Operating System

Linux

Steps to reproduce this

Steps:

  1. Run the code on p5.js web editor

Snippet:

// Paste your code here :)
function setup() {
  createCanvas(400, 400);
}

function draw() {
  if(frameCount === 1) noLoop()
  background(220);
  rect(10,20,30,40)
  noStroke()
  rect(50,60,70,80)
}

function mousePressed()
{
  loop()
}

I am not sure if this is the intended behaviour.

The above code would give two rectangles with no outline or stroke (after pressing the mouse). The last noStroke call sets the doStroke variable in renderer2d.js to False which is then used for the next draw call.

You can check the correct behaviour when frameCount == 1

Ideally, it seems we should reset the doStroke and other related variables back to their default values at the end of each draw call to have no side effects.

In the same way, we reset the canvas matrix for rotate, scale and other transform calls.

tushar5526 avatar Aug 12 '22 08:08 tushar5526

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms. Thank you!

welcome[bot] avatar Aug 12 '22 08:08 welcome[bot]

I think we may not want to reset them back to default values because a common pattern is to set up some properties in setup that we expect to never change in a sketch, and I think preserving the ability to do that would be good.

I think having consistency and predictability would also be good, though. A compromise might be to implicitly wrap draw in push() and pop() to go back to the previous state afterwards. But I also wonder (I haven't confirmed this) whether reverting transformation would break some sketches if they transform in setup but expect transformation to be reset before draw. Although it would still be inconsistent, maybe transformation still could reset to default while everything else reverts to a previous value?

Does anyone else have thoughts on this?

davepagurek avatar Aug 12 '22 12:08 davepagurek

The biggest problem I see here is that this will likely be a breaking change and affect the behaviour of many existing sketches, and so will not be something we can consider adding to the library until at least the next major release.

limzykenneth avatar Aug 14 '22 09:08 limzykenneth

Agreed. This would break a lot of things and there would be many hidden side effects. I think for best practices users should just call stroke at the start in draw if we want something to be stroked. Similar for other settings.

tushar5526 avatar Aug 14 '22 10:08 tushar5526

Thanks @tushar5526 @davepagurek @limzykenneth for the discussion. I agree that this will affect many existing sketches, and there are many ways to work around it. I will close this issue for now. Please feel free to reopen it in the future for further discussion, like around the next major release.

Qianqianye avatar Oct 23 '22 03:10 Qianqianye