Packaging, distribution, portability #66
Open
Conversation
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
…instance, and caches resources that already loaded.
…mising on the bundle. Experimenting with embedding images in the bundle as data URIs
…ing the canvas after all. Fixed a few other related bugs and moved the imports into "bundle-contents.js".
…es GPUDevice::destroy.
nohren
reviewed
May 11, 2025
nohren
reviewed
May 11, 2025
nohren
reviewed
May 11, 2025
nohren
reviewed
May 11, 2025
…he core useEffect
… tree shaking of the imported resources.
…s values affect the component render
…d entries into config.js. Inclusions are now explicit dynamic import lambdas, so the cache functions can detect and call them; however, webpack and rollup seem to use them differently.
…er; replaced webpack and rollup with vite; converted bundle-contents to "core" and "full" bundle profiles; renamed "inclusions" to "staticAssets", which are "url" base64-encoded images and "raw" text strings; renamed the Matrix component module to the JSX extension; built out a test scaffold at tools/test/index.html to manually test the various deploy options.
…d text, never GPU resource handles; renamed renderer "formulate" to "configure"; WebGPU renderer's configure function needs early returns after each major await, in case there's a new config; the render loops are now locally stored closures; renderers now have start and stop functions; fixed bugs in the REGL and WebGPU mirror passes; WebGPU bloom pass now enforces texture dimensions are greater than zero; the react component now stores the renderer type in a useRef and returns early from renderer init awaits to prevent multiple renderers from instantiating.
|
The switch to vite simplified the project's build and test cycle enormously, and afforded some big changes:
The React component test app contains some additional inputs to really put the renderers through their paces, and to help identify lingering problems. Currently, I believe there are none. But as soon as we add a speed control slider, it'll get wacky again, because currently each timed phenomenon (glyph cycling, rain falling, forward motion) uses a multiple of the current time instead of an accumulation of the multiplied delta time. The renderer base class will probably wind up governing speeds for this reason. I'll keep the PR open for a week or so, in case @nohren has questions or feedback. Afterward, PRs should be much much smaller. |
"rain instance" --> "renderer" in error message
…ue before destroying it
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.