Hacker News new | ask | show | jobs
by mrandish 121 days ago
Alex,

It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty, it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's what Gemini says:

> "Specifically, this is a Scrim or Easing Gradient. Instead of a simple transition between two colors, it uses 16 color stops to mimic a "cubic-bezier" mathematical curve. This creates a smoother, more natural fade than a standard linear gradient, but it forces the browser to calculate high-precision color math across the entire surface during every scroll repaint."

My Firefox smooth scrolls like butter on thousands of pages, so you might want ask your web designer to test on non-Mac, iGPU laptops with hiDPI and consider the performance cost of web pages with always-running subtle background animations in a world of diverse hardware platforms. In case it helps, here's the animation with the gradient layers disabled so you can see all 6,400,000 pixels which are being recalculated every scroll line (https://i.imgur.com/He3RkEu.jpeg).

8 comments

You're right - I'll remove that now until we can get it more performant or drop it altogether. This wasn't something we caught during testing. I appreciate the feedback!
While you are at it, it would be good, if the post was readable at all, without having to run JS on the page.
It rendered perfectly, without JavaScript, in Emacs EWW.
I think perhaps Emacs does not support the `hidden` attribute?

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

If you check the source (not the DOM) the actual content is loaded in `<div hidden="" id="S:0"> ...` which is then moved/copied into the proper main content div in the DOM using a JS event it seems.

It must have sent it differently if the browser reports it can’t do JavaScript.
I used to try EWW sometimes, but it sometimes made whole Emacs crash at unpredictable times, so I stopped trying to use it. But good to know, maybe I will try again in the future, hoping it becomes more stable/safe.
I don’t think EWW has ever made my Emacs crash. I wanna say I’ve been using it regularly since Emacs 27.
> to Commodore 64 level

That’s unfair to C64 which can smooth scroll very well.

Exactly! The C64 could control where the beam started painting. To move the screen a pixel you just wrote the the x and y offsets to two 8-bit I/O registers. Only after scrolling 7 or 8 pixels you had to copy memory around. I was relatively easy to get this right smoothly and since everything was in sync with the beam it was easy to make tear free.

Shaking effects that did not require memory copy were even easier.

I owned a C64. Remember how buttery smooth the interfaces of those '80s computers were?
Not Apples. But Amigas, omg those were smooth.
I was green with envy, when I saw how fast and smooth a C64 scrolled some text (iirc it was some machine code monitor). My Amstrad CPC464 had no text mode and the Z80A CPU was clearly overwhelmed with shifting the whopping 16KiB RAM of the graphics buffer or even just rendering a line of text.
CPC allows some level of smooth scrolling, albeit not as good as C64. Lack of a text mode is a problem too as you said.
fewer layers between software and hardware...
Not by repainting the whole screen every frame!
Modern browsers don’t repaint the whole screen every frame either.
Eh, the NES is better because you get two entire screen buffers. The C-64 gives you only one offscreen row or column to repaint every coarse scroll, and the colormap is fixed so you gotta move all of its bytes while racing the beam.
While I agree with your point, I don't understand why you added:

> here's what Gemini says

Surely, if people care to see LLM generated text, they can do it themselves.

It's a clearly marked quote that adds more details. It's perfectly fine.
It's not adding more details in this case, it's adding incorrect information. CSS gradients are rasterized once during paint into a bitmap by the browser. Theres no recalculation going on per scroll unless something invalidates the gradient bitmap, and it doesn't matter how many steps the gradient has or how complicated it is.

The real issue is something was causing the container with the gradient to repaint on every scroll.

That’s helpful information but it doesn’t mean the use of Gemini is unwelcome. A human could have rendered the initial analysis too, and then you could have just replied to the human, correcting him or her. Why is the source of the analysis such an issue?
IMO it's because people have learned not to trust LLMs. It's like using AI code generators – they're a useful tool if you know what you're doing, but you need to review the material it produces and verify that it works (in this case, verify that what it says is correct). When they're used as a source in conversations, we never know if the "dev" has "reviewed the code," so to speak, or just copy and pasted.

As for why people don't like LLMs being wrong versus a human being wrong, I think it's twofold:

1. LLMs have a nasty penchant for sounding overly confident and "bullshitting" their way to an answer in a way that most humans don't. Where we'd say "I'm not sure," an LLM will say "It's obviously this."

2. This is speculation, but at least when a human is wrong you can say "hey you're wrong because of [fact]," and they'll usually learn from that. We can't do that with an LLM because they don't learn (in the way humans do), and in this situation they're a degree removed from the conversation anyway.

Notice how many times Claude Code was mentioned in this blog post nee advertisement?
To read using Firefox, or any browser/HTML pager, without Javascript or CSS:

   (
   printf 'GET /blog/tuis-are-easy-now HTTP/1.0\r\n'
   printf 'Host: hatchet.run\r\n\r\n'
   )|busybox ssl_client hatchet.run \
   |(echo "<meta charset=utf-8>";grep -o "<p.*</p>") > 1.htm
   firefox ./1.htm
Don't blame my Commodore 64. Once a program is loaded it, runs with 50 or 60hz refresh rate, which is very smooth! Take that! :-)
imagine paying 3k$ for a laptop that can't even handle cubic gradients?
FWIW, this page looks just fine in a text-only browser running in textmode, no X11, no Javascript, no CSS, on an old, underpowered computer