filter() crashes on createGraphics(WEBGL) buffers

[aashu2006]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• p5.strands
• WebGL
• DevOps, Build process, Unit testing
• Internationalization (i18n)
• Friendly Errors
• Other (specify if possible)

p5.js version

v2.2.1 and v2.2.2-rc.2 (reproduces in both)

Web browser and version

Google Chrome 145.0.7632.75 (Official Build, 64-bit)

Operating system

Linux Ubuntu 24.04 LTS

Steps to reproduce this

1. Create a WebGL canvas.
2. Create a secondary createGraphics() buffer in WEBGL mode.
3. Draw a shape on the graphics buffer.
4. Call filter() on the graphics buffer.

The sketch crashes with a TypeError

Snippet:

function setup() {
  createCanvas(100, 100, WEBGL);

  const g = createGraphics(100, 100, WEBGL);
  g.noStroke();
  g.fill('red');
  g.circle(0, 0, 40);

  g.filter(INVERT); // crashes
}

Console Error:

Uncaught (in promise) TypeError: e.getColor is not a function
    at _makeFilterShader (p5.min.js)
    at filter (p5.min.js)
    at Graphics.filter

Calling filter() on a createGraphics(WEBGL) renderer causes a runtime TypeError originating inside the WebGL filter shader pipeline.

[aashu2006]

Hii, @ksen0 I would be interested in working on this, if that’s okay.

[ksen0]

Thanks for finding this! As you observe, it was introduced in 2.2. I've assigned it to you. As you know there's a lot of active development around this, so when you have some idea(s) for the solution, please post an update here and tag @davepagurek for visibility

[davepagurek]

I suspect part of the problem is that a p5.Graphics doesn't automatically get functions defined on p5.prototype. We add shader hook objects to fn here to make them visible:

p5.js/src/strands/strands_api.js

Line 716 in 9c7a97f

fn[name] = hook;

...but that doesn't get added to p5.Graphics. One approach could be to manually add this to p5.Graphics there too, although arguably there's a wider problem of deciding whether p5.Graphics should automatically get fn extensions added to it with some exceptions (like draw loop things), or whether by default nothing is added except what we manually add. See also #8170 for some previous discussion on that if you have thoughts!

[aashu2006]

Thanks for the insight @davepagurek I will look into how shader hook functions are attached and whether they are missing on p5.Graphics instances. I will post findings shortly.

[aashu2006]

Hi @davepagurek I checked and confirmed that p5.Graphics does not inherit the strands hook functions added to p5.prototype e.g - getColor. Since _makeFilterShader passes the graphics instance as the p5 scope, shader callbacks attempt to call p5.getColor, which does not exist on p5.Graphics.prototype, causing the TypeError.

This seems to be an architectural mismatch between how strands attaches hooks (to p5.prototype) and how p5.Graphics is structured (manual prototype composition).

I see 2 possible directions:

1. Extending strands hooks to p5.Graphics.prototype
2. Adjusting how the shader scope binds p5 for Graphics contexts

[davepagurek]

I think (1) is likely the easiest to start with -- in addition to setting fn[name] = hook, also explicitly attaching to p5.Graphics.prototype too -- but I think updating how p5.Graphics works generally is also a possibility, but needs a bit more discussion. I think I generally fall in the camp of thinking p5.Graphics should be equivalent to a p5 instance with the exception of the draw loop rather than the reverse. @limzykenneth do you have some thoughts here?

Since doing that is sort of blocked on higher level decisionmaking, it could make sense to do a quick fix using (1) at first, and then we could do a longer term fix for p5.Graphics later if we decide that's the way to go.

[aashu2006]

@davepagurek getTexture and other strands API functions are installed via initGlobalStrandsAPI directly onto p5.prototype, not through createShaderHooksFunctions

So addressing only createShaderHooksFunctions is not sufficient. p5.Graphics is missing the broader strands API layer as well. It seems we could either extend initGlobalStrandsAPI to also attach its functions to p5.Graphics.prototype or rethink how p5.Graphics inherits from p5.prototype.

[davepagurek]

Yep you're right! We'd need it there too. Basically anywhere in p5.strands where we augment fn we'd also have to augment p5.Graphics.prototype.

[aashu2006]

@davepagurek I went ahead with the approach we discussed. Instead of patching individual functions, I mirrored all fn (p5.prototype) augmentations onto p5.Graphics.prototype.

• Permanent strands APIs e.g - getTexture, vec*, dot etc. are mirrored via a helper augmentFn with unconditional overwrite.
• Temporary shader hooks e.g. getColor are mirrored via augmentFnTemporary and restored in deinitStrandsContext.

This ensures createGraphics(WEBGL).filter() has access to the full strands layer without leaking temporary hooks. WebGL unit + visual tests pass locally, and the manual test confirms the crash is resolved. Let me know if this direction looks good. Thanks 🙂

[davepagurek]

that sounds great, thanks!