Live data from Hacker News

Self-updating screenshots

interblah.net

1–10 of 80 posts

Re: Self-updating screenshots

#5
I’ve wondered about doing screenshots from the e2e test run, even keeping docs/ all together in the same repo so when you update the documentation and need a new screenshot you add a new test

Re: Self-updating screenshots

#6
Very cool.

For the small casual games I've been vibe coding, I always start from a place where the application has a CLI where it can run headless, rendering to offscreen texture, with a a screenshot command as well as performance instrumentation. It takes no time to include all this, and gives the agent a way to automate the ui and inspect important things. It also lets me trivially have the agent update screenshots.

Not as neat as being part of the build process, but I will now add that.

Re: Self-updating screenshots

#8
Same, I've added a .#screenshots derivation. High up-front effort but almost zero maintenance afterwards.

Bonus: since you're generating screenshots programmatically anyway, you can generate a pair of each with your app's light/dark theme, and swap them in/out depending on prefers-color-scheme: dark. elements work in GitHub READMEs, too: https://github.com/CyberShadow/CyDo#readme

Re: Self-updating screenshots

#10
I wrote a gui app once that ran on a safety-critical platform. I ended up stuffing a rendering of the gui (rendered offscreen) into shmem at I think 24hz, and rendered that screenshot into the safety critical application. I passed clicks (no typing for this gui) back from the statically rendered image updating on a cadence, to the offscreen GUI.

Worked well. Not quite the same as this, but that’s what this reminds me of.

Post reply on HN