fix builtin global accessors for instance mode in strands shaders

[aashu2006]

Resolves #8877

Changes:

Fixed installBuiltinGlobalAccessors in strands_api.js so that the builtin globals like mouseX and width work correctly in instance mode when used inside strands shader callbacks.

Previously only window.mouseX was intercepted, so in instance mode (p.mouseX), the values got hardcoded into the shader instead of becoming live uniforms.

Now the function also installs property interceptors on p5.prototype and p5.Graphics.prototype. It correctly handles both data properties (like mouseX) and getter based properties (like width, which delegates to this._renderer?.width) by saving the original property descriptor and delegating to it when strands isn't active.

Also I've added a unit test that verifies myp5.mouseX and myp5.width return strands nodes inside hooks and normal numbers outside.

PR Checklist

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

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@2e4f545/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@2e4f545

Commit hash: 33e1b43

Previous deployments

94fb7b6

• https://raw.esm.sh/pr/p5@20e3b14/lib/p5.min.js
• https://pkg.pr.new/p5@20e3b14

---

This is an automated message.

[eupthere]

I think we need to check _isGlobal here, to avoid adding accessors to the global window object on instance mode.

[aashu2006]

thanks for catching it @eupthere, I've added the _isGlobal check so we only define window accessors in global mode now. Also updated the tests to use instance access (myp5.width instead of window.width) since the test framework runs in instance mode anyway.

[davepagurek]

Is there a reason for using a symbol here as opposed to a string?

[aashu2006]

Using a symbol here to avoid any chance of colliding with existing properties on the instance/prototype. A string like _strands_mouseX would also work, but symbols are guaranteed to be unique and stay out of things like Object.keys() and for...in, so the backing store remains hidden.

happy to switch to strings if you think that's simpler 🙂

[davepagurek]

Do they need to be stored on the prototype? Elsewhere we store this on strandsContext.fnOverrides, e.g.:

p5.js/src/strands/strands_api.js

Line 143 in 82135bb

strandsContext.fnOverrides[name] = fn[name];

fn in addons is a shortcut to p5.prototype, so it seems like maybe this should be using that same system.

[aashu2006]

switched to storing the original descriptors on strandsContext.fnOverrides instead of the prototype, and also switched from Symbol to a string key for the per-instance backing store, it should be cleaner now.

[davepagurek]

nice!

[aashu2006]

Hi @davepagurek, I added the _isGlobal check so the window accessors are only defined in global mode. Also updated the tests to use instance access (myp5.width) instead of window.width, since the test environment runs in instance mode anyway.

Also moved the original descriptor storage to strandsContext.fnOverrides and switched from Symbols to string keys for the backing store, like you suggested.

[aashu2006]

Also, the earlier CI failure was in p5.Framebuffer.js (a createElement mock issue) unrelated to this PR's changes.

[davepagurek]

One thing around fnOverrides is that those are automatically put back again when you init/deinit strands:

p5.js/src/strands/p5.strands.js

Lines 32 to 87 in 82135bb

	function initStrandsContext(
	ctx,
	backend,
	{ active = false, renderer = null, baseShader = null } = {},
	) {
	ctx.dag = createDirectedAcyclicGraph();
	ctx.cfg = createControlFlowGraph();
	ctx.uniforms = [];
	ctx.vertexDeclarations = new Set();
	ctx.fragmentDeclarations = new Set();
	ctx.computeDeclarations = new Set();
	ctx.hooks = [];
	ctx.backend = backend;
	ctx.active = active;
	ctx.renderer = renderer;
	ctx.baseShader = baseShader;
	ctx.previousFES = p5.disableFriendlyErrors;
	ctx.windowOverrides = {};
	ctx.fnOverrides = {};
	ctx.graphicsOverrides = {};
	ctx._randomSeed = null;
	if (active) {
	p5.disableFriendlyErrors = true;
	}
	ctx.p5 = p5;
	}
	function deinitStrandsContext(ctx) {
	ctx.dag = createDirectedAcyclicGraph();
	ctx.cfg = createControlFlowGraph();
	ctx.uniforms = [];
	ctx.vertexDeclarations = new Set();
	ctx.fragmentDeclarations = new Set();
	ctx.computeDeclarations = new Set();
	ctx.hooks = [];
	ctx.active = false;
	ctx._randomSeed = null;
	p5.disableFriendlyErrors = ctx.previousFES;
	for (const key in ctx.windowOverrides) {
	window[key] = ctx.windowOverrides[key];
	}
	for (const key in ctx.fnOverrides) {
	fn[key] = ctx.fnOverrides[key];
	}
	// Clean up the hooks temporarily installed on p5.Graphics.prototype (#8549)
	const GraphicsProto = p5.Graphics?.prototype;
	if (GraphicsProto) {
	for (const key in ctx.graphicsOverrides) {
	if (ctx.graphicsOverrides[key] === undefined) {
	delete GraphicsProto[key];
	} else {
	GraphicsProto[key] = ctx.graphicsOverrides[key];
	}
	}
	}
	}

Currently we use special keys, so it doesn't quite work as expected -- it'd be adding things to fn with those keys on deinit. So if we're opting into this system, we may have to update the logic a little bit to make sure the name we store it as is the original so that it works with this resetting logic, and possibly updating the resetting logic to handle descriptors. Possibly it makes sense to make a similar fnDescriptorOverrides if that logic is different enough. But then it also resets them after Do we also reset the flag saying whether we've installed globals, so that if they're correctly placed back, we also correctly replace them again the next time we make a strands shader?

[aashu2006]

@davepagurek yes you're right fnOverrides gets reset by initStrandsContext() on every modify() call, which means the stored descriptors wouldn't survive. It can also lead to deinitStrandsContext() overwriting the getters during restore.

I've removed the fnOverrides storage entirely and now use the original descriptors captured in the closure directly.

[davepagurek]

Thanks for the updates, looks good!