[p5.js 2.0 Bug Report]: p5.Graphics does not have the setAttributes function

[davepagurek]

Most appropriate sub-area of p5.js?

• [ ] Accessibility
• [ ] Color
• [x] Core/Environment/Rendering
• [ ] Data
• [ ] DOM
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [x] WebGL
• [ ] Build process
• [ ] Unit testing
• [ ] Internationalization
• [ ] Friendly errors
• [ ] Other (specify if possible)

p5.js version

2.0.5

Web browser and version

Any

Operating system

Any

Steps to reproduce this

Steps:

1. Create a new WebGL graphic via let g = createGraphics(200, 200, WEBGL)
2. Try to set its attributes via g.setAttributes({ antialias: true })

Currently this fails because the function doesn't exist.

This is because, in 2.0, we add the usual p5 methods to p5.Graphics by explicitly setting up every addon module a second time by calling it on p5.Graphics.prototype: https://github.com/processing/p5.js/blob/095f22090d774d28bdc3d977d0bc5b2e646233d6/src/core/p5.Graphics.js#L676-L693

However, this is not a comprehensive list of addon modules (the renderergl one is missing, which has setAttributes), but also it means that if a third-party addon adds a method to p5, it will not get added to p5.Graphics.

So I think the fix for this shouldn't be just to add the renderergl module, but to see if we can fix addon registration to also work on p5.Graphics.prototype. (@limzykenneth, do you have thoughts on how to accomplish that? Would we get ordering issues if we make p5.registerAddon do both p5.prototype and p5.Graphics.prototype?)

[limzykenneth]

Would we get ordering issues if we make p5.registerAddon do both p5.prototype and p5.Graphics.prototype?)

I think this is probably the approach to take however p5.Graphics itself is technically itself an addon so if we assume no specific order in which addon are added, p5.Graphics may be added after another addon is already added, ie. at the point where p5.registerAddon is called, p5.Graphics may not exist.

We can possibly change the internal implementation of p5.registerAddon somewhat inline with what we previously talked about which is to do the prototype attachment at the last minute, perhaps just before the decoration stuff in the constructor in similar way?

[davepagurek]

Do you think deferring registerAddon would have the same issues but just at a later time? We might still need some special casing there to make sure p5.Graphics comes first. There was some earlier discussion on addon dependencies and ordering in https://github.com/processing/p5.js/issues/7797, but this feels maybe a bit different because it feels like everything should automatically have p5.Graphics as a dependency if it is in the build. So maybe that means we need to do some internal special casing for p5.Graphics regardless?

[limzykenneth]

The idea I have currently is not quite to defer registerAddon but rather for the fn argument to be something like an empty object whose properties are then attached to the prototypes of both p5 and p5.Graphics as the first step of the constructor, ie. like how we store the decorations in a Map then clear it out once applied, we can possibly do the same with fn.

It is possible to explore making p5.Graphics more core to the library implementation as I couldn't quite resolve fully this whole relationship between p5.Renderer, p5.Graphics, and p5 itself when refactoring the whole renderer code. It is tricky to avoid major breaking changes though I find.

[VANSH3104]

@davepagurek and @limzykenneth I understand the issue a little bit, but could someone please explain it in more detail? Also, I was thinking instead of changing how registerAddon works, could we just wait until all addons are loaded and then copy references of any missing methods from p5.prototype to p5.Graphics.prototype?

[limzykenneth]

Hi @VANSH3104, this issue is a bit complex and there are some quick fix although for a longer term fix there are some mechanics that needed to be worked out. The main thing is that all modules within p5.js core are written as addons and they don't have (or at least shouldn't have) any higher priority than a third party addon.

Attaching methods to p5.Graphics assumes that some of the methods should be usable on p5.Graphics and that p5.Graphics have largely the same surface area as an p5 instance. This means there are some hardcoded modules that are added onto p5.Graphics but third party addon couldn't quite access it in an ergonomic way. The idea around waiting for all addons are loaded don't quite work because there is no easy way to know in code when that is, each addon registration event is independent of each other and not controllable nor visible by the sketch author. The only point we identified where we know addons has all been registered is in the constructor which is the idea we mentioned above.

@davepagurek There is something I just remembered as well, I think there is a deliberate choice to not attach all methods to p5.Graphics and only attach rendering related methods, ie. things like math functions etc are not attached in anticipation that those will use the instance methods instead. Which means there may need to be a more specific means for addon to attach something to p5.Graphics instead of attaching everything onto it.

[VANSH3104]

@limzykenneth thanks for the explanation that makes the internal behavior much clearer now but One question would it make sense to let addons optionally declare whether their methods are meant to be graphics-accessible (for example, via a flag in registerAddon())? That might help filter which methods get mirrored to p5.Graphics.prototype in a cleaner way.

[limzykenneth]

@VANSH3104 It may not be in registerAddon()'s signature itself as it is possible that only some of the methods are meant to be attached to p5.Graphics while some are not. If you have some idea about an additive API design for this we can review it here, the main thing is that we cannot change the signature of registerAddon() while the arguments passed to the addon callback function, especially fn, can be more flexible to a certain extend.

[Rudrxxx]

Hi! @davepagurek I submitted a PR (#8286) that fixes this issue #8264 by safely routing noSmooth() through setSmoothing() when available and falling back when not. Since #8264 was marked as a duplicate of this issue, Issue #8170 appears to be a broader internal architecture discussion, while my fix targets the runtime crash specifically. Please let me know if any modifications are needed—I’d be happy to continue working on related follow-up tasks if needed. please feel free to assign me this issue.