[WIP] p5.js 2.0 Updates

[zenozeng]

processing/p5.js#7488

• 2.x tests
• createCanvas
• class Renderer2D
• canvas.getBoundingClientRect
• p5.js 2.0.1 missing type declarations

[limzykenneth]

Hi @zenozeng, I've only just recently came across this issue, I had been wanting to look into helping update p5.svg to use p5.js 2.0 semantics but have always put it off as I knew it is likely to be relatively complex. It is great to see that you are starting to look into it already.

Having an SVG renderer has always been a frequently requested feature in p5.js as I'm sure you are aware of which your library works towards it. As such in the design of the internal API and addon API of p5.js 2.0 I have been considering the required surfaces to help that implementation be more semantic. I'm not sure how far you have looked into the API yet, I still need to find some time to properly document it, but I'm happy to help with making p5.svg a test implementation for a full SVG renderer for p5.js that, if you are happy with it, eventually may get incorporated into p5.js core itself as another natively supported renderer.

From just some quick glance at your code here, it seems you already have many of the same if not similar idea behind the API we use for p5.js 2.0 which is awesome. If you have any questions on the API or implementation, I'm very happy to answer any of them. If you'd like, I can also try to find some time to work on a proof of concept renderer using the new API to give an idea around how the full implementation can be structured. Let me know what works for you!

I'm very excited to see a svg renderer in p5.js as I think it is really long overdue!

[zenozeng]

@ksen0 @limzykenneth

Thank you so much for reaching out. This project has been maintained on and off for 10 years, and I haven’t been able to dedicate substantial time to it recently due to work commitments (I was working over 90 hours weekly during the past period). I’m deeply grateful to contributors like @BL451, @nkymut, @spencerflem and @immjs for keeping this repository alive, and I sincerely hope that integrating SVG into p5.js’s core repositories will attract more contributors.

The design goal of p5.js-svg is to enable seamless SVG vector support in p5.js with minimal SLOC (Source Lines of Code). To achieve this, the architecture is structured in two layers:

1. The first layer (svgcanvas) provides a CanvasRenderingContext2D API with SVG as the rendering backend.
2. The second layer implements p5.js’s Renderer based on the svgcanvas CanvasRenderingContext2D API, adapted from p5.js’s built-in Renderer2D.

Regarding p5.js 2.0, I have a few questions:

• Does the official team plan to provide simultaneous support for both 1.x and 2.x? As an addon maintainer, should we maintain compatibility with both versions or focus solely on 2.x moving forward?
• Native async/await support is a long-awaited feature for developers like myself, but I’ve been uncertain about its adoption within the community, especially among non-technical users.
• Based on the current implementation, if 2.x compatibility is required, p5.js-svg would need to maintain a dedicated branch separate from the main codebase.

[limzykenneth]

@zenozeng We are also thinking that if it eventually aligns, integrating p5.svg into core would be a good thing to have and we can start with getting this addon aligned first and figure things out step by step. In regards to the questions you have, they are all great questions, see below:

Does the official team plan to provide simultaneous support for both 1.x and 2.x? As an addon maintainer, should we maintain compatibility with both versions or focus solely on 2.x moving forward?

Yes, we currently support both 1.x (bug fixes only) and 2.x (bug fix and feature enhancement). The website, web editor, and other partners will default to 1.x for now until August 2026 with option to switch to 2.x, and after August 2026 the default version will be 2.x so that there will be more than 1 year to transition. For addon maintainers, there are a few options:

• Maintain separate 1.x compatible and 2.x compatible versions of the addon
• Release 2.x compatible version of the addon and deprecate the 1.x compatible version of the addon
• If implementation allows, maintain a version of the addon that works with both 1.x and 2.x versions

It is up to you as maintainer of your addon project which option you'd prefer to go with, as each has its own pros and cons, we don't necessarily prescribe an option. Most addons I've worked with to update go with the third option because their implementation are relatively simple, with p5.svg using the new renderer syntax however I believe it would be difficult to maintain compatibility with both versions in one codebase so you may need to consider either of the other two options instead.

Native async/await support is a long-awaited feature for developers like myself, but I’ve been uncertain about its adoption within the community, especially among non-technical users.

As per the timeline above, we have planned for a very long transition period, during this period we will work on outreach campaign aimed at educators to update their teaching materials which should help trickle down this switch between preload and async/await. From a technical standpoint, I personally believe the mental overhead between having to use preload vs async/await is roughly equivalent as preload is itself a bit of an unnatural concept as well, so I believe it wouldn't be a fundamental barrier to learning any more than preload would be.

Based on the current implementation, if 2.x compatibility is required, p5.js-svg would need to maintain a dedicated branch separate from the main codebase.

Per transition plan above, it depends on whether you'd want to keep dual maintenance of 1.x and 2.x compatibility. 1.x, as mentioned above, will only receive bug fixes going forward so from an addon point of view should be relatively stable and static. You would have a better idea on the status on the 1.x compatible version of p5-svg though to determine whether you would like to keep it actively maintained or around as a bug fix branch only.