-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[p5.js 2.0 RFC Proposal]: Renderer system refactor #7016
Comments
I think this is going to be one of the more important things to get out of 2.0! A couple things that probably need clarifying though:
|
The
This can possibly be its own importable module separate from the more complete WebGL renderer (which will include
For batch rendering I still need to better understand the trade off for implementing it to know for sure. Ideally I would like implementing a renderer by following For vertex functions, a visitor pattern is my current preference, although my understanding of the pattern mainly comes from Rust's Serde crate so I'm not 100% sure that is the idea being proposed. Perhaps this may need to be worked out in practice or in a proof of concept. |
Currently, renderer methods aren't directly made public, with |
Most of what I'm thinking of in terms of defining a renderer is done in the proof of concept To register the renderer, we need to add a function to the addon library API to add the custom renderer class to this list and it will be instantiated here. Additional magic will need to be used to attach all public methods of the custom renderer to |
Sounds good! We could always enforce the convention that underscore-prefixed things are private, or maybe just forward all enumerable keys if we can use something like private methods for other stuff. (Can build systems transpile it to regular non enumerable properties if we want compatibility?) |
For truly private things I would prefer to use native private methods as you linked. It is pretty well supported so we may not even need to transpile it to something else. |
Btw, today I came across this project: https://github.com/humanbydefinition/p5js-ascii-renderer (demo: https://editor.p5js.org/humanbydefinition/full/ibclfMqlk) It got me thinking, if one wanted to make something like this as a renderer, would that mean having to also reimplement the transformation push/pop stack? Currently, that's also part of what each renderer has to provide, since 2D mode piggybacks on the native canvas's stack for some state. It's probably not necessary for v1, but just another thing to think about -- maybe there's a nice abstracting for that too in there somewhere. |
I think it would be good to be able to generalize an implementation for push/pop as well but it may bring a lot of complexity into core that the 2D renderer will likely still want to overwrite with native canvas stack in its own implementation still. |
Increasing access
A more flexible renderer system enables p5.js to be used in a larger variety of rendering situation that a user may need, eg. to be print medium, controlling plotter/robot arm, SVG, and more. This enables context in which the default provided renderers of p5.js may not meet some user's specific needs (such as a renderer for Braille display perhaps?)
Which types of changes would be made?
Most appropriate sub-area of p5.js?
What's the problem?
p5.js 1.0 is bundled with two renderers: 2D and WebGL. They corresponds to the HTML Canvas
2d
andwebgl
context respectively. However, there had been requests over the years to add additional renderers such as an SVG renderer or a renderer with scene graph capabilities. As the web evolve, we are also seeing new a possible standard renderer being developed, ie. WebGPU.As currently implemented, adding a new renderer to p5.js is not an easy task which involves many parts that expects to behave differently depending on whether the current sketch is in 2D or WebGL mode.
The constant value to determine whether a canvas is in 2D or WEBGL mode is also not easily extendable by addon libraries.
What's the solution?
With p5.js 2.0, the renderer system is redesigned and tweaked with a few key points.
p5.Renderer
class which bothp5.Renderer2D
andp5.RendererGL
classes inherit from will now act more like an abstract class that it is meant to be.p5.Renderer
class will determine a set of basic properties and methods any renderer class inheriting from it should implement, while extra functionalities can still be implemented on top. (eg. all renderers should implement theellipse()
method but the WebGL renderer will also implement asphere()
method that 2D renderers don't need).p5.Renderer
class should never be instantiated directly.P2D
andWEBGL
) are harded coded into functions likecreateCanvas()
making creating a new rendering mode difficult without also modifying core functionalities.p5.renderers
object with value being the class object of the renderer (that inherits fromp5.Renderer
class).For an addon library to create a new renderer to work with p5, it will need to first create a class that inherits and implements the
p5.Renderer
abstract class, then register the renderer under thep5.renderers
object.When a sketch author wants to use the addon provided renderer above, they can use the following code when creating a canvas.
For usage that are more similar to p5.js' own renderers, constants registration can be exposed to addon library authors as well. In this case, it is recommended to make the constant value a
Symbol
matching behavior in the core library itself.Core question
Part of the motivation for this proposal is to enable a leaner build of the library for users who only use the 2D renderer but not the WebGL renderer and vice versa. If someone uses only the 2D canvas, there is no need for most if not all of the WebGL components to be included.
This creates a question, should p5.js still be bundled with both renderers for distribution? What about new renderers in the future? There are a few options for this:
The third options is probably too extreme and probably should not be considered. Either of the first two options are open for discussions.
Pros (updated based on community comments)
Cons (updated based on community comments)
p5.Renderer
abstract class) will be needed.Proposal status
Under review
The text was updated successfully, but these errors were encountered: