Posted by baldvinmar 13 hours ago
This lib runs a a RAF animation loop every 8ms across every component on the page that causes the entire document to repaint.
The comment above appears of the AI generated sort: // One shared animation frame: step every live component, park when idle. // The delta is capped so a background-tab pause never becomes one giant step.
The "JellyEngine" instead of just calculating the jelly animation on pointer events is recalculating for every active component on the page every frame.
This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'.
Agreed the comments look a bit slop-ish but I don't see anything obviously wrong with its approach, and the core loop is running in microseconds for me when nothing is happening.
Cursor idle, viewport on the button examples. 3ms repaint every 8-11ms. Animation frame points to the code i mentioned.
The problem isn't doing work on a website, its if you have an idle task that is taking up a significant portion of the frame budget then its easy to have frame drops when you do significant work like clicking, scrolling, browsing.
Idle work showing up in flamecharts is usually the thing to be cautious of.
It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limited by either your vsync rate or hardware.
That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work.
This page, however, has an animated SVG and moving DOM elements in the header which consume far more resources than the widgets it is trying to showcase. Compare usage before and after deleting the header element (`section.hero`) in the inspector to see for yourself.
> That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work.
Your comment doesn't say this at all:
> > This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'.
> It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limited by either your vsync rate or hardware.
Am I missing something? Are you referring to some other part of the thread?
Anyway, something like this only needs to paint when states change or animations are running. That's an easy optimization to make here if it doesn't do it already. And games don't even bother with it, they repaint all UI even if it doesn't change.
Point being: your comment made me sad and I needed to lighten myself up a bit.
To be clear, I'm not saying it's fine to constantly render when you know nothing changed. I'm saying the load from this should be very small. Most of the performance issues from this page are actually from the header animation, which you can delete in the inspector to see a significant drop in usage (mine went from ~35 to ~6.6 CPU).
All this work to replicate the animated blobbiness of Liquid Glass. I thought everyone hated it! So, then, why is this a thing?
It does in my mind. I fully expect visiting any of reddit.com, github.com, notion.so, or meet.google.com to have the chance to pin a cpu core at 100% for as long as the site is open.
At this point, I expect the average webpage to use more CPU than any of the video games I play. The only reason I had to upgrade to my current machine is because a 2021 CPU (intel gen 11) wasn't capable of running notion.so or google meet anymore, it still ran all the video games I care about just fine.
CPU bound games examples: Chess, Go, Final Fantasy XIV, Elite Dangerous, and any competent Civilization / 4X or turn-based strategy game. Yes, you can dial up the graphics on these to force them to be GPU bound, but they’re each CPU bound in their own unique ways. Perhaps none such games appeal to you, but as with above, extrapolating from personal preferences is a non-starter.
Non-tech people teach each other to force-quit apps to stop their battery drain. Websites aren’t apps, so their phone ‘randomly’ gets hot sometimes and they either have no idea why or just try closing all tabs in a vague hope that it works. Sometimes a webpage uses up all their data for the month downloading ads and so they stop using the web over cellular at all.
This is the baseline level of competence that improving the web must be aiming for — not ‘web developers will understand that the tab is using lots of battery and must be closed’. Making the web better is not about making the web significantly more battery-hungry, no matter how pretty it might seem. No visual advancement in radio button UX is worth a continuous repaint in JavaScript.
The websites I mentioned use more cpu and memory than most games in Civilization the series, which are largely competently developed. My previous laptop could play civ 5 at a higher framerate than it could scroll github diffs or notion pages. Civ 5 handled full-speed keyboard input, while notion doesn't let me input text at my roughly 100 wpm typing speed.
I agree that we shouldn't be expecting users to figure out how to close the right tab, however I'm reporting the way things currently are, which is that webpages are poorly optimized messes.
But many smaht people out there don't know that.
For instance, the mouse cursor is composited on the GPU during scanout. That means simply moving your cursor requires zero rendering.
Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.
These cool demos come up now and again and it always takes me a minute to remember I have reduced motion. But for that minute I was disappointedly clicking around thinking "Whats the big deal?"
If I click and hold then move the mouse away to release, I assume an element should not register that as a click. As-is, this is inconsistent: the button registers a click, the checkbox does not.
But for a single like button, an effect slider, or magic search bar? It would be be a lovely touch.
I think now that llms make it super easy to add anything that its important not to add everything.
Neave was a personal hero of mine back then... hope you're well if you're reading this!
By contrast, most of the other controls do seem to stick to the cursor, such as jelly-resizable.
Also, the "Placeholder" control seems to fail to actually make the placeholder disappear when clicked in.
------------------
Original:
How does that make anything about this "physics-based"? I'm not being snarky, I'm genuinely trying to figure out what part of this is completely going over my head. I don't see any "soft-body physics" interactions, but maybe I don't understand what to look for.
I don't see any deformation or elastic collision physics, and those are usually the most obvious things that I associate with "soft bodies" in engineering/physics.
You sure about that? “Turn on Reduce Motion” was a common bit of advice for people who were looking for ways to make Liquid Glass livable.
1. The AI they used called it "physics-based" as a hallucination (probably due to the popular "JellyCar" game), and they went with it because they don't know better.
2. They don't know better, so they asked the AI for a "physics based" system, and the AI was too sycophantic to correct them.
Either way, it's slop.
EDIT: It's also WILDLY inconsistent. Click and drag on a button and the shape doesn't change. Click and drag on an on/off and the deformation follows the mouse. Merely click an on/off and the deformation does not follow the the little circle thingy, or bear any relation to the action of the button.
Some of the things are inoffensive, spinner dots, progress bars, accordion menus. But basically anything that deforms on click related to where you click are nonsense.
EDIT 2: The buttons in the demo area apparently do have distortion that follows the mouse, but on the left side they don't? For me this is just a lot of bafflingly inconsistent gloss that makes me wonder what's going on or why one thing behaves differently than others, and what that means for actual functionality. Rather than just interacting with the UI.
very important to filter out and choose who you engage with