← Back to context

Comment by jlukic

18 hours 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'.

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.

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

    https://postimg.cc/sQpZxxzv

    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.

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

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

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

      2 replies →

  • Presumably in a video game the majority of the screen changes every frame. Not so in web pages.

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

      9 replies →

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

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