streams
WebGL-Fluid-Simulation
streams | WebGL-Fluid-Simulation | |
---|---|---|
5 | 109 | |
1,331 | 14,242 | |
0.6% | - | |
6.0 | 0.0 | |
4 days ago | 5 months ago | |
HTML | JavaScript | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
streams
-
Backpressure explained – the resisted flow of data through software
Yup, this is what WHATWG's Streams spec[0] (linked in the article) says. It defines backpressure as a "process of normalizing flow from the original source according to how fast the chain can process chunks" where the reader "propagates a signal backwards through the pipe chain".
Mozilla's documentation[1] similarly defines backpressure as "the process by which a single stream or a pipe chain regulates the speed of reading/writing".
The article confuses backpressure (the signal used for regulation of the flow) with the reason backpressure is needed (producers and consumers working at different speeds). It should be fairly clear from the metaphor, I would have thought: With a pipe of unbounded size there is no pressure. The pressure builds up when consumer is slower than producer, which in turn slows down the producer. (Or the pipe explodes, or springs a leak and has to drop data on the ground.)
[0] https://streams.spec.whatwg.org/#pipe-chains
[1] https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...
- Streams Standard
-
Streams and React Server Components
// https://streams.spec.whatwg.org/#example-transform-identity const { writable, readable } = new TransformStream(); fetch("...", { body: readable }).then(response => /* ... */); const writer = writable.getWriter(); writer.write(new Uint8Array([0x73, 0x74, 0x72, 0x65, 0x61, 0x6D, 0x73, 0x21])); // "streams!" writer.close();
-
Goodbye, Node.js Buffer
Yeah, in your case I think most of the complexity is actually on the ReadableStream side, not the base64 side.
The thing that I'd actually want for your case is either a TransformStream for byte stream <-> base64 stream (which I expect will come eventually, once the simple case gets done), or something which would let you read the entire stream into Uint8Array or ArrayBuffer, which is a long-standing suggestion [1].
---
> Why does de-chunking a byte array need to be complicated
Keep in mind the concat proposal is _very_ early. If you think it would be useful to be able to concat Uint8Arrays and have that implicitly concatenate the underlying buffers, [2] is the place to open an issue.
---
> You have made me realize I don't even know what the right venue is to vote on stuff. How should I signal to TC39 that e.g. Array.fromAsync is a good idea?
Unfortunately, it's different places for different things. Streams are not TC39 at all; the right place for suggestions there is in the WHATWG streams repo [3]. Usually there's already an existing issue and you can add your use case as a comment in the relevant issue. TC39 proposals all have their own Github repositories, and you can open a new issue with your use case.
Concrete use cases are much more helpful than just "this is a good idea". Though `fromAsync` in particular everyone agrees is good, and it mostly just needs implementations, which are ongoing; see e.g. [4]. If you _really_ want to advance a stage 3 proposal, you can contribute a PR to Chrome or Firefox with an implementation - but for nontrivial proposals that's usually hard. For TC39 in particular, use cases are only really valuable pre-stage-3 proposals.
[1] https://github.com/whatwg/streams/issues/1019
[2] https://github.com/jasnell/proposal-zero-copy-arraybuffer-li...
[3] https://github.com/whatwg/streams
[4] https://bugs.chromium.org/p/v8/issues/detail?id=13321
-
Are you using generators?
// AudioWorkletStream // Stream audio from Worker to AudioWorklet // guest271314 2-24-2020 let port; onmessage = async e => { 'use strict'; if (!port) { [port] = e.ports; port.onmessage = event => postMessage(event.data); } const { urls } = e.data; // https://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md const { readable, writable } = new TransformStream(); (async _ => { for await (const _ of (async function* stream() { while (urls.length) { yield (await fetch(urls.shift(), {cache: 'no-store'})).body.pipeTo(writable, { preventClose: !!urls.length, }); } })()); })(); port.postMessage( { readable, }, [readable] ); };
WebGL-Fluid-Simulation
-
That is some extremely impressive water physics, especialy for a place you only visit once. How did they do it? (MAJOR SPOILERS FOR 4.2 WORLD QUEST)
It kinda reminds me of this fluid simulation website. The site is about a computer graphics technique that simulates the motion and appearance of fluids such as water, smoke or fire. You can use your mouse to move around the screen to see the simulation, also can change how the fluid simulation works by adjusting the sliders in the control panel next to it.
-
Goodbye, Node.js Buffer
Typed arrays are essential for web apps that use WebGL and WebGPU. Being able to send this typed data to run computations on the GPU in parallel can give you 1000x speed up.
You can see it in action on this WebGL fluid simulator[0] by PavelDoGreat.
[0] https://github.com/PavelDoGreat/WebGL-Fluid-Simulation
- WebGL Fluid Simulation
-
Water – Oimo.io
this one is much smoother: https://paveldogreat.github.io/WebGL-Fluid-Simulation/
previously: https://news.ycombinator.com/item?id=34422948
-
This thing is wild!
Not a video. WebGL Fluid is the website.
- The website has been found!
-
A lost website
Sure here it is
-
Saw this ad that made me have major feelings from childhood
Off the top of my head I'm thinking of WebGL Fluid Simulation
- Webgl Fluid Simulation
-
Here you go: Golden Beryl on a magnetic stirrer ... in slow mo!
Here is poor man's stirrer: https://paveldogreat.github.io/WebGL-Fluid-Simulation/
What are some alternatives?
AudioWorkletStream - fetch() => ReadableStream => AudioWorklet
react-fluid-animation - Fluid media animation for React powered by WebGL.
encoding - Encoding Standard
Phaser - Phaser is a fun, free and fast 2D game framework for making HTML5 games for desktop and mobile web browsers, supporting Canvas and WebGL rendering. [Moved to: https://github.com/phaserjs/phaser]
console - Console Standard
lively - Free and open-source software that allows users to set animated desktop wallpapers and screensavers powered by WinUI 3.
proposal-array-from-async - Draft specification for a proposed Array.fromAsync method in JavaScript.
portfolio-site
url - URL Standard
react-native-gcanvas - react native canvas based on gpu opengl glsl GCanvas -- A lightweight cross-platform graphics rendering engine. (超轻量的跨平台图形引擎)
proposal-async-iterator-helpers - Methods for working with async iterators in ECMAScript
BestBuy-GPU-Bot - BestBuy Bot is an Add to cart and Auto Checkout Bot. This auto buying bot can search the item repeatedly on the ITEM page using one keyword. Once the desired item is available it can add to cart and checkout very fast. This auto purchasing BestBuy Bot can work on Firefox Browser so it can run in all Operating Systems. It can run for multiple items simultaneously.