jlukic
4 days ago
Saw the window was a bit laggy so thought I'd delve deeper to figure out what was going on.
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'.
wbobeirne
4 days ago
Running a performance profile in Chrome doesn't back this up for me, and looking at the loop it looks like it maintains an active `Set<JellyComponent>()` of which components to update, and clears them out when they stop moving.
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.
jlukic
4 days ago
Here's the perf profile, just to clarify.
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.
Rohansi
3 days ago
That's from Lottie, the animations that play in the header and footer of the page. Shrink your window until they disappear and try again.
naikrovek
3 days ago
Is it? I am in the middle of the page, the header and footer are well off into the distance not being rendered, and I see the same pattern.
Rohansi
3 days ago
Zoom in, take a look at what code is running, and you'll see it's all `lottie_light.min.js`. Being offscreen doesn't mean it's doing nothing. In fact, it looks like once it shows once it keeps spinning its RAF loop forever. Shrink your window so it disappears, reload, and then profile.
edoceo
3 days ago
Oh, yea, "you're holding it wrong"
raincole
3 days ago
? In this very particular case, yeah, the original commenter was holding it wrong, as they inspected the wrong thing. People sometimes hold things wrong and it's okay.
Rohansi
4 days ago
> 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.
Philip-J-Fry
4 days ago
A website shouldn't be pinning CPU or GPU. When people run a game they expect some sort of battery drain. People don't expect that some websites will thrash your CPU/GPU like a game.
Rohansi
4 days ago
> A website shouldn't be pinning CPU or GPU.
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.
globnomulous
4 days ago
> > A website shouldn't be pinning CPU or GPU.
> 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?
Rohansi
3 days ago
Sorry, I meant to say that it was what I was suggesting. Video games render a lot more than the widgets on that website. Rendering less takes less time, so your `requestAnimationFrame` loop idles longer between executions waiting for vsync, which means your CPU or GPU usage is not pinned.
user
3 days ago
goobatrooba
4 days ago
> Yes my car is running all night while it stands in front of my house, but it's not really a waste of resources or a nuisance because generators do the same thing.
moralestapia
3 days ago
Your analogy is wrong. The rendering engine is the generator.
theodric
3 days ago
It's mining Bitcoin!
yesithinkso
3 days ago
You know nothing about software if you really think this.
He's right - the DOM also has observers.
The difference is what is rendered, not that observers are involved and the concept of looping.
Millions use React - you want to talk about performance?
holoduke
3 days ago
If you take about optimizing then games are the prime example of doing that. You don't load textures every frame into gpu memory. Tou don't load vertices into memory every frame. Sure they repaint every pixel every frame. But low level your display driver is doing that anyway. The cpu cycles are not in sending the RGB value to each pixel. We are far beyond that bandwidth issue. Recalculating every single position in a css styled document is pretty heavy. There are millions of calculations done to solve flex boxes, floats, percentual widths etc. this example is doing something like that. Super heavy. Super inefficient. Super bad.
pennomi
4 days ago
Presumably in a video game the majority of the screen changes every frame. Not so in web pages.
Rohansi
4 days ago
My point was more that rendering a few widgets at 60+ FPS is nothing for anything with a GPU, and everything has a GPU these days.
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.
dxdm
4 days ago
Waste the cycles, everyone has too many cycles, is it even waste if the cycles would just go unused, GPUs are expensive, they better do their bit, who's got no GPU, go play somewhere else without your GPU, pal. It's all a game, anyway.
Point being: your comment made me sad and I needed to lighten myself up a bit.
Rohansi
4 days ago
Yes, visual effects and animations in UIs burn cycles just to make it look nicer. Doesn't matter if it's a website or the native system UI.
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).
bmitc
3 days ago
What happens when you have 50 tabs open using this "engine"?
Rohansi
3 days ago
Nothing? I actually measured it incorrectly in the comment you replied. With nothing happening on the page Chrome's task manager reports ~0.1 CPU usage for the tab. Almost all of the overhead on this page is from the header and footer animations [1] and not the widgets. Browsers limit things like `requestAnimationFrame` in inactive tabs anyway so even if it was bad it wouldn't be devastating.
bmitc
2 days ago
Interesting. Thanks for the details.
yesithinkso
3 days ago
> GPUs are expensive
Do you know that regular HTML and CSS use GPU all the time?
dxdm
3 days ago
Nothing wrong with browsers using resources to do useful work. I'm just not a fan of bloat that eats resources because they're assumed to always be available.
That's what this thread is about, I thought.
altairprime
4 days ago
Video games only get away with this because their energy draw is obvious: one launched the video game, so one expects the power draw. Visiting a web page does not have that action-reaction causality in people’s minds. Having a random web page introduce maximally-inefficient repaints also leads browsers to start reducing timeslices — especially those with any sort of power drain cognizance, such as Safari — which, here, leads to hella janky animations that can’t cope without their inefficient repaint loop.
All this work to replicate the animated blobbiness of Liquid Glass. I thought everyone hated it! So, then, why is this a thing?
TheDong
4 days ago
> Visiting a web page does not have that action-reaction causality in people’s minds
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.
altairprime
4 days ago
As a web developer, I am not included in the perception difference I describe. I am also 0.000001% and not a representative sample of People As A Whole Or Even As A Majority Or Significant Fraction. So while my personal awareness is akin to yours, extrapolating from that towards the masses is a dead end exercise.
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.
TheDong
4 days ago
If the geneva convention didn't ban torture, I'd say that web-developers should be forced to actually try and use the apps they develop.
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.
qurren
3 days ago
They should also be forced to walk around town with a GDPR cookie banner pasted over their face covering half of their field of view. And then although automatic doors open for most people, for them specifically, the automatic doors shut. The doors are postered with "would you like to subscribe" newsletter ads. They have to manually open each one of them.
pibaker
4 days ago
This is like saying "I fully expect visiting that neighborhood to have the chance of getting mugged." A true statement and an incredibly sad one.
lexicality
3 days ago
Is your browser running the javascript event loop on the GPU? Because mine isn't
adithyassekhar
3 days ago
The state of the web when you want to compare a website to the most intensive thing a pc can do.
hbcdbff
4 days ago
A website isn’t a videogame
yesithinkso
3 days ago
Braindead take.
A videogame is expensive to render because of several MB models, constantly moving camera, and other things.
The concept of observing elements is not even new.
yesithinkso
3 days ago
I get what you're saying.
These downvoters act like native JS doesn't do the exact same thing with event listening and observing the DOM. So does React and other FE frameworks.
Philip J Fry is either being disingenuous or genuinely doesn't know that game rendering has often several MB models, is often raycasting, maintaining camera calculus, and a lot more.
moralestapia
4 days ago
The browser and OS does that as well (unless absolute zero updates and you don't even move your pointer around).
But many smaht people out there don't know that.
ben-schaaf
3 days ago
This is just plain false. Retained UIs like the DOM and what your OS uses only ever render when something changes, so the vast majority of the time they sit idle. There's extensive effort throughout the entire stack to do as little work as possible.
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.
Rohansi
3 days ago
> Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.
You're right that they avoid unnecessary painting but it is not this granular anymore. It used to be but rendering is so much faster these days where it is cheaper to just render a bit more than tracking dirty regions. It's easily visible on Android where you can enable "Show view updates" and see the entire textbox view updates when the cursor flashes. The docs say the same thing.
https://developer.android.com/reference/android/view/View#in...
ben-schaaf
3 days ago
Wow, that's quite silly - and might partially explain some of the worsening battery life on Android. GTK4 also removes such an API, but just like those docs say, dirty rects are still calculated internally. You can enable the same visual debugging in GTK4 and see that dirty rects are done the same as they always have been.
Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.
Rohansi
3 days ago
> Wow, that's quite silly - and might partially explain some of the worsening battery life on Android.
It's likely the same on iOS. You'd have to try implementing it to really see why it isn't practical.
Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region. Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.
> Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.
Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.
ben-schaaf
2 days ago
> Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region.
The way this is done everywhere is to invalidate the entire area of the button. Buttons usually change background on hover/click anyway, so it just doesn't make sense to do more. Text input is special because these widgets can be very large, sometimes spanning the whole screen, so you want fine-grained dirty regions.
> Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.
I've never heard of anyone adding a general Widget-Level cache, considering that most UI elements don't change position that would be quite expensive. In any case the rendering is still a "pure" function regardless of whether you're using dirty regions or not, so not sure what you're trying to say here.
> Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.
That is definitely weird, but it still clearly shows that the regions are being tracked.
yesithinkso
3 days ago
That doesn't mean that the process stops, it runs indefinitely because it has to.
The DOM does this. React does this.
Did you know CSS even invokes the GPU for certain tasks?
You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.
ben-schaaf
3 days ago
> That doesn't mean that the process stops, it runs indefinitely because it has to.
The processes don't stop, no, but they do pause and go idle, waiting for the next event to come in. Not sure what that has to do with this.
> The DOM does this. React does this.
What does react have to do with any of this discussion, and what do you mean by "this"?
> Did you know CSS even invokes the GPU for certain tasks?
Whether the GPU or CPU does work is unrelated to how frequently and how much of the screen is rendered. Damage regions work just fine for GPU-based rendering.
> You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.
Part of my job is maintaining a retained mode UI library. I've literally written some of the parts that handle damage regions, as well as the GPU-based rendering. But do go on about how I don't know how any of this works.