Repository navigation
[p5.js 2.0+ Bug Report]: Loading indication #8922
Description
Most appropriate sub-area of p5.js?
- Accessibility
- Color
- Core/Environment/Rendering
- Data
- DOM
- Events
- Image
- IO
- Math
- Typography
- Utilities
- WebGL
- WebGPU
- p5.strands
- Build process
- Unit testing
- Internationalization
- Friendly errors
- Other (specify if possible)
p5.js version
2.0+
Web browser and version
any
Operating system
any
Steps to reproduce this
Steps:
- Run the below code
- Observe that while loading, the canvas is blank with no feedback to user at all (this is a regression compared to p5.js version 1)
Snippet:
// for p5.js versions 2.0 or later only
async function setup() {
createCanvas(400, 400);
// Delay to simulate loading large files (for demo only, not actual usage)
await fakeLoad(7000);
// Your usual setup things below
background("#EB5580");
fill(255);
circle(width / 2, height / 2, 100);
}
function draw() {
circle(mouseX, mouseY, 20);
}
async function fakeLoad(delay) {
await new Promise(resolve => setTimeout(resolve, delay));
}
Activity
ksen0 commentedon Jun 16, 2026
A minimal PR on the main p5.js branch for loading indicator should have the following effect. When the example code is run, there should be a "Loading..." indication. The actual content of this indication can be made more complex in the future (to reflect the discussion in this thread) but it should be as minimal as possible for now, and it should work without any changes to the code above.
EDITED to add: The solution should also be isolated in the codebase and extensible in the future. You can check #6795 for a discussion of future updates, but please do not implement any of the idea in that thread; this issue is specifically about "Loading" state in p5.js.
Also note that sketches like this:
should still work and not have excessive loading messages anywhere. The solution should not rely on
background().Please feel free to @ me and @limzykenneth if you're uncertain or have other ideas!
This Issue has been reserved for the CodeDay microinternship. If it is not complete within that internship in the next couple of months, then we will release it to volunteers. Thanks for understanding!
BHARATH0153 commentedon Jun 16, 2026
ksen0 commentedon Jun 17, 2026
Hi everyone, this is reserved for the CodeDay microinternship. If it is not completed by them, then it can be opened to volunteers. But for now, please do not make PRs or volunteer - thanks for understanding!
Jextic commentedon Jul 13, 2026
Hello @ksen0,
@gojoshin and I have been working on this issue. After exploring the codebase for a while, we figured the best place for the loading indicator to appear and disappear would be right before and after the setup function call in main.js.
As for the code that implements the loading indicator, we plan on creating a loading.js module in the p5.js/src/core folder since it needs to be isolated in the codebase. Since the loading indicator needs to be as minimal as possible, would it be sufficient to just have a "loading..." text at the center of the screen?
limzykenneth commentedon Jul 21, 2026
@Jextic A couple things.
presetupandpostsetup? That way it is a bit more semantic and reduce complexity in the core start up.loading...text which has localisation issue while being static, it would be nice to have basic animation instead. It can be a gradient based animation by @SableRaf in Visual loading indicator fallback while assets are loading #6795: https://openprocessing.org/sketch/2619980 or ideally something not text based, if at all possible. Two, it would be ideal to prepare the system in such a way that it does not block future implementation where a user can define their own basic loading animation. This ties into not having it be too tightly coupled with core code and as much as possible being basically an addon, if there are functionalities missing that make this difficult or impossible, do let me know.Jextic commentedon Jul 21, 2026
Thanks for the feedback! I managed to decouple the loading indicator by using
p5.registerAddon(loading)and I think I could use thepresetupandpostsetupproperties of thelifecyclesobject to implement the loading indicator functions. As for the loading indicator, I'm currently trying to implement a spinning circle animation to replace the "loading..." text and will commit these changes once I'm done.ksen0 commentedon Jul 30, 2026
Thanks for the work and reviews everyone! So after some discussion with @limzykenneth and @davepagurek, I have merged #8997 but kept this issue open. The initial implementation does provide helpful feedback to users when their sketches take a while to load, and it's good to have it ready before the completion of the v2 switch.
The main point about the instance mode feedback, to address this, a canvas-based animation rather than css would be needed, such as the spinning star in Raphael's example. @Jextic does your team want to do a follow up to update the loader to switch from using css to using p5 API to make a canvas-based loading animation, or should the followup be opened to voluneers? Working in this direction would make it easier to ensure behavior is consistent in global and instance mode.
Here are 2 sketches by Ken that show global vs instance mode:
(These are both using the current loading animation, which is already useful and has been released in the
2.3.2patch)Jextic commentedon Jul 31, 2026
Hi @ksen0,
Thanks for updating me on this! We'd like to continue working on this if possible. I believe we can modify the current loading indicator animation to implement Raphael's spinning p5 logo instead. We currently have two implementation plans in mind (although we're definitely leaning towards the 2nd one):
document.createElement('canvas');and have the spinning p5 logo at the very center of the canvas. We recently discovered that I can usefn.createCanvasto intercept the canvas from the user's sketch code. That way, the loading indicator can be perfectly positioned at the center of the canvas that the user created. Once the user's sketch is fully loaded, the temporary canvas with the loading indicator will be removed.The 1st approach seems like an interesting idea so I thought I would include it as food for thought. The 2nd approach aligns more with the direction that you have in mind so that's what we plan on working on. We have a rough implementation of the 2nd approach where we switched from the css styled indicator to a canvas-based one and it seems to work well. Are there any suggestions or modifications to the 2nd approach that would better align with what the team has in mind?
limzykenneth commentedon Aug 3, 2026
@Jextic Approach 2 is likely preferred. There are a few things to consider here.
The time in which the sketch is being awaited in
setup()is not known, it can happen before the user callcreateCanvas(), after they callcreateCanvas(), and before/after they call any drawing functions (includingbackground()). How would the approach account for these cases?Also do use the new decorator pattern if the idea is to intercept calls to
createCanvas().SableRaf commentedon Aug 3, 2026
I agree. The animated cursor was a fun experiment but it has a bunch of drawbacks which you rightly underlined.
ksen0 commentedon Aug 3, 2026
Thanks for the input @limzykenneth @SableRaf , @Jextic I agree with what they wrote, thanks!
rizzhal commentedon Aug 10, 2026
I want to work on this issue
SableRaf commentedon Aug 10, 2026
Hi @rizzhal, thanks for wanting to help! This issue isn’t available at the moment, as @Jextic is already actively working on it.
Jextic commentedon Aug 21, 2026
Sorry for the late update but it seems like my partner @joshin is having issues with his computer. As of now, he is unable to access his computer, where most of his progress is stored, and is getting it repaired as soon as possible. He's currently trying to re-implement the changes on his other device but it might take some time. He says that he'll try get it done by the end of Monday, August 24th.
As a quick progress update: He was able to get the spinning p5 logo working using the p5 API code. Before his computer died, he was figuring out the best way to intercept the canvas when taking into account the fact that the canvas can be created at anytime.
limzykenneth commentedon Aug 26, 2026
@Jextic Let us know if there are any updates. In terms of intercepting the canvas, what do you mean by that? If you mean be able to catch when a user call
createCanvaswithin their sketch, I would recommend the new decorator feature which is create for this kind of use case. The original issue is a bit long and I still need to properly document it, you can also checkout the implementation for how to use it in the parameter validation module and in the p5.Vector module. You can also ping me directly if it is still confusing on how to use it.If it is easier, feel free to file a draft PR and we can look at the implementation work in progress.
Jextic commentedon Aug 28, 2026
My partner has yet to respond about his progress and I haven't seen any commits on our branch so I'll take a look at the decorator API instead and see how I can work with it. I think this might be exactly what we were looking for so thanks for linking the decorator API issue!