p5.js
p5.js copied to clipboard
Resetting environment variables after each draw call
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:
- 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.
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!
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?
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.
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.
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.