Repository navigation
loading.js uses canvas-based animations and sketch instances have their own indicator #9119
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
Open
Jextic
wants to merge
13
commits into
processing:main
Choose a base branch
from
Jextic:issue-8922
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
281c7e7
loading.js uses canvas-based animation and each sketch instance will …
Jextic 1c46bb1
Small descriptions and grammar fixes
Jextic b3a4f09
Updated loading.js tests to use mockP5 and mockP5Prototype
Jextic a6e57bc
Merge branch 'main' into issue-8922
Jextic 9752dcc
"noLoadingIndicator()" function added
Jextic 02c56b6
Added test for "noLoadingIndicator()"
Jextic 7c62ee8
Merge branch 'main' into issue-8922
Jextic 6ebe59c
Merge branch 'processing:main' into issue-8922
Jextic 338dced
custom loading indicator (first implementation)
Jextic aeded15
gets rid of loading indicator if promises are unresolved
Jextic 2ee4751
optional transparent background for loading indicator
Jextic bb9fc0a
Merge branch 'processing:main' into issue-8922
Jextic 492394e
Merge branch 'main' into issue-8922
Jextic File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing we don't handle yet is the case when something else moves around the canvas from this initial position, or has other elements on top of the canvas (e.g. UI elements; we don't want this canvas intercepting their mouse events) which they might not want a loading canvas to go on top of. All of those seem somewhat difficult to handle without it being brittle.
Do we have ways to either opt out of showing a loading indicator (would that be passing a custom animation that does nothing? still creates a second canvas though), or ideally to reuse the same canvas? The latter does seem like it'd address all the issues, but comes with some additional things to handle, namely:
createCanvasis called. For the default p5 logo spinner we could check the renderer type and handle both; for custom loaders, if they don't want to do that, they could just make sure to create their canvas first before setting up their custom loader so that the type doesn't changeSorry to take a step back and discuss some fairly different approaches; just want to make sure we're preempting issues that'd come up by adding a second canvas to every sketch before moving forward!
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we perhaps have something a bit equivalent to
createCanvasthat is used in thedrawLoadingAnimationfunction that if not called will not create a second canvas and can also be used to create a 2D or 3D canvas depending on renderer chosen?Reusing the same canvas will need more work though at this point to accommodate different renderers given we need to get the API used inside
drawLoadingAnimationto behave consistently regardless. Also the problem of how to undo the loading animation once it is completed without erasing what is already on the canvas, perhaps by saving the current pixels of the canvas and writing it back after?To provide a set of p5 like functions without worrying about it clashing with the global definition, we can potentially use the pattern similar to here: https://github.com/antfu/p5i#usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably want to avoid creating extra 3D canvases if possible since there's a fairly low limit in the number of active contexts the browser supports at once, so I think if you're creating extra canvases, it would make sense to limit them to 2D. If we end up not wanting to have loaders on the same canvas, then we maybe just need a way to say "I don't want any loading animation canvas" separate from "here's my own loading animation"
I suppose if you're interleaving drawing with loading in
setupit's going to be pretty hard to do that. It might mean that we would want to have a way to say "I'm done loading" earlier than the end ofsetupif we have a loader drawn to the main canvas and you intend to do some drawing that you don't want overdrawn by the loader, so you just see the loader while it's loading and then you just see your content afterwards?Does loading start showing up right before
presetuphooks start, or is it earlier? If it's right as the p5 lifecycle starts then would the p5 methods already be available?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if we stick with a 2D context always then it might be more straightforward to still do an additional canvas since we can't reuse the canvas already used for 3D, also the user may not have created a canvas in the first place for us to know which renderer they are going to use.
If that is the case then the undo issue won't be a concern and we can ignore it. The original question of a more dynamic sketch at the start that move its position or covered by other elements feels like there could still be a solution though, I think as long as we can keep the loading canvas as a sibling to the main canvas it should take care of most things, there are some edge cases such as when the user use CSS specifically to target only the main canvas.
The loading do start with presetup so p5 methods might be available already, need to confirm how it behaves though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sticking with 2D for simplicity is ok if we're going to stick with a separate canvas, but then let's just add an escape hatch to disable this entirely if we do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we add a flag
p5.loadingAnimationwhich when set tofalsewill skip the loading animation stuff entirely so a canvas won't be created?