Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jelly UI: Soft-body physics for native HTML form controls

jelly-ui.com

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Jelly UI: Soft-body physics for native HTML form controls

#201

Post by bmitc »

Rohansi wrote: post #104
dxdm wrote: post #95

Earlier quoted context omitted.

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.

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 signi…

What happens when you have 50 tabs open using this "engine"?

Re: Jelly UI: Soft-body physics for native HTML form controls

#202

Post by bmitc »

blauditore wrote: post #35
orliesaurus wrote: post #13

If I were younger I would love this. nowadays I spend most of the time tweaking websites to remove this stuff using local stylesheets...or using dark + read mode... how times have changed.

I like the fact that it gives animated feedback to emphasize what is happening/being altered. Native components don't always do that very well. Animations are not just artsy fluff, they have real UX value (if done right, of course).

The animations, in this case, are not helpful. They distract from what you're trying to do. And components that don't give feedback are bad. It's trivial to have different color palettes for over, click, release, etc.

Re: Jelly UI: Soft-body physics for native HTML form controls

#203

Post by Rohansi »

ben-schaaf wrote: post #197
Rohansi wrote: post #182

Earlier quoted context omitted.

> 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" a…

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…

> 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.

Re: Jelly UI: Soft-body physics for native HTML form controls

#204

Post by Rohansi »

bmitc wrote: post #201
Rohansi wrote: post #104

Earlier quoted context omitted.

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 signi…

What happens when you have 50 tabs open using this "engine"?

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.

[1] https://news.ycombinator.com/item?id=48986612

Re: Jelly UI: Soft-body physics for native HTML form controls

#205

Post by ben-schaaf »

Rohansi wrote: post #203
ben-schaaf wrote: post #197

Earlier quoted context omitted.

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…

> 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…

> 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.

Re: Jelly UI: Soft-body physics for native HTML form controls

#206

Post by bmitc »

Rohansi wrote: post #204
bmitc wrote: post #201

Earlier quoted context omitted.

What happens when you have 50 tabs open using this "engine"?

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. [1] https://news.ycombin…

Interesting. Thanks for the details.

Re: Jelly UI: Soft-body physics for native HTML form controls

#209

Post by ChiperSoft »

baldvinmar wrote: post #117
DonsDiscountGas wrote: post #36

Okay I know this is gonna sound rude but who in the world would want form controls that behave this way?

Sometimes we built for the pure joy of making. Practicality is a bonus.

That is visible in your code. I was mildly skeptical at first because it just didn't seem like it was doing much more than other design systems. Then I looked at the code.

You've built something really great here, your grasp of web components is incredibly strong, and the way you use TypeScript is very light handed in a way that made the code just a delight to read through, in a way I've not had in many years. It's been a while since I looked at a new library's codebase and learned something new, so thank you for that!

This may sound silly, but I think you've laid the foundation here for the next Bootstrap / MUI. It just needs more expandability and distribution options.

Post reply on HN