p5.js 2.0 Updates

[limzykenneth]

Hi @ffd8, moving the discussion from the p5.js repo over here. I have tested out P5Live locally and as mentioned in the issue, it seems the main thing not working is overwriting values of global p5.js values such as mouseX, mouseY, or frameCount. Due to the way these values are attached to the global object, the way it works now is that if the user overwrites that value in global mode, we assume the user are doing it intentionally, ie. wanting to use a variable with name frameCount and don't want p5.js to update it or for their update to the value change p5.js behavior. I think this approach leads to less unexpected behavior in case the user did accidentally or intentionally use these global variable names.

For P5Live however, since the intention is to change these value to affect p5.js behavior I can see why it is not working. I have done some tests and have found a potential solution. While modifying the global variable does not work, modifying the instance value still works:

// Instead of 
frameCount = 1;

// This works
p5.instance.frameCount = 1;

However, from skimming through the code where I can, I can't find a good point to obtain p5.instance from the iframe window object. What I would suggest is potentially to do a slight refactor to use window.postMessage instead to communicate from the main process to the iframe process, that way things are more firewalled and separated and the code within the iframe can be written as a p5.js addon, giving it a bit more structure.

In the iframe's own code, it can listen through window.addEventListener("message", () => {}); and depending on message either modify the p5 instance value as needed or do any other operation from there, ie. using message passing for this semantically multithreaded application instead of direct variable access.

Let me know if this make sense and I'm happy to help with implementation if needed. 😄

[ffd8]

Hey @limzykenneth - thanks for having a look into it and time flew by while working on other features (coming sooon) – nevertheless, just took another attempt at bringing v2 into P5LIVE and hit the following issues:

First off, you can check out the latest dev version 1.7.0

I now disable the p5sound lib similar to the online editor and as you suggested, am now setting the p5.instance._____ vars (which luckily also works for p5 v1). Good idea to switch things to postMessage, I had been using dispatchEvent for such things – but will consider refactoring.

So I got almost all errors to disappear (minus, it complaining about my extending the cursor() function.. why does it care?) – and thought it was still frozen like before, until I toggled off the editor (CTRL + E) and voila, the sketch was alive and tracking my mouse (if I had been randomly placing things, it would have been fine). So v2 is loading (!), however none of my mouseEvents are making it from P5LIVE (with editor visible) down into the iframe with p5 (v2) running.. super strange that it works fine with v1 (editor on or off), but v2 stops that (only with editor visible) = is there some major global changes with the mouse in v2 that I also have to account for??

Within latest P5LIVE dev 1.7.0, you can see how I pass the mouse from index.html and receive it within /includes/templates/p5live_sketch.html.

Thanks for any insights you have on p5's v2 development and what might have changed with the global mouse.

Here's a v2 test sketch to try out:

// manually set p5 version in P5LIVE
// p5 = '2'

function setup() {
	createCanvas(windowWidth, windowHeight)
	print(VERSION)
}

function draw() {
	background(0, 5)
	circle(mouseX, mouseY, 100)
	circle(random(width), random(height), random(15))
	
	if(mouseIsPressed){
		background(255, 50)
	}
}

[limzykenneth]

is there some major global changes with the mouse in v2 that I also have to account for??

Yes there is indeed, didn't notice you were listening to those events before. In 2.0 we have switch from MouseEvent (listening to mousedown, mouseup etc) to PointerEvent (equivalent pointerdown, pointerup, etc) for better cross compatibility between mouse and touch interfaces.

Here's a list of events currently listened to relating to mouse:
'pointerdown'
'pointerup'
'pointermove'
'dragend'
'dragover'
'click'
'dblclick'
'wheel'

You may find that just switching over the event name where necessary would be enough but feel free to ping me again if you need me to look at any problems. Also not sure if it is relevant for your use case but there will be an extension to the Events API for addons: processing/p5.js#7946, it should be backward compatible and just adding new features available for addons.

[ffd8]

@limzykenneth Ahaaaaa – ok, that is definitely what was causing the issue and a significant change. Indeed, I need to pass these events into the iframe if the editor is visible, since that div covers/steals the mouse action from the canvas below it. Then unfortunately, I can't switch entirely to pointEvent since v1 of p5 doesn't recognize that, so I manually catch if v1 or v2.

Regarding my extending of the cursor() / noCursor(), which produces the following console.log warning:

You just changed the value of "noCursor", which was a p5 global value. This could cause problems later if you're not careful.

You just changed the value of "cursor", which was a p5 global value. This could cause problems later if you're not careful.

Is there a simple way to disable these 'p5 global value' change warnings (without disabling entire FES)? Or a better way that I should be changing the value without triggering it? I understand it's there as a warning for beginners who may give variables the wrong name – but in my case it's intentional (needed to REALLY hide the cursor via CSS when one calls the functions:

appendToFunction('noCursor', ()=>{document.body.style.cursor = 'none'})
appendToFunction('cursor', ()=>{document.body.style.cursor = 'crosshair'})

function appendToFunction(fn, callback) {
    window[fn] = (function(fn){
        return function() {
            fn();
            callback();
        }
    }(window[fn]));
}

[limzykenneth]

Is there a simple way to disable these 'p5 global value' change warnings (without disabling entire FES)? Or a better way that I should be changing the value without triggering it? I understand it's there as a warning for beginners who may give variables the wrong name – but in my case it's intentional (needed to REALLY hide the cursor via CSS when one calls the functions:

Yes there is plan to implement individual switches in FES to disable specific feature rather than the whole FES (mainly inspired by your use case), I still need to find a bit of time to do it though but I think I should have time this summer once I get some backlog out of the way. I don't think there's necessarily an easy way to distinguish between unintentional overwrite and intentional overwrite so it may just have to be disabling global variable overwrite checks itself.

[ffd8]

Sounds great and nice to hear this use case inspires it. Yeah, I'm sure there's no way to tell intensional vs unintentional – unless there was something like a pushOverwrite() / popOverwrite() that would temporarily disable a FES when making changes?? No problem if not – will be fine just disabling the overwrite FES once it's available.