Self-updating screenshots

(interblah.net)

73 points | by bjhess 19 hours ago

11 comments

  • furyofantares 1 hour ago
    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.

  • CyberShadow 59 minutes ago
    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. <picture> elements work in GitHub READMEs, too: https://github.com/CyberShadow/CyDo#readme

  • maderalabs 14 minutes ago
    Nice! I actually started to build this exact thing a couple years back, and ended up abstracting it out to something more generic with https://picshift.io/. That said, I still love the screenshot use case - the original name of this project was ScreenSync ;)
  • schneems 34 minutes ago
    This is neat. I wrote https://github.com/zombocom/rundoc. It has a similar feature. The main driver is to produce tutorials so it also puts the output of commands run back in the document.
  • LeoDaVibeci 12 hours ago
    I've needed this so many times. BTW this should be a meme: "I think this might be the neatest thing I’ve built in X that nobody will ever notice."
  • efortis 16 hours ago
    same here, but linking to the screenshots used for pixel diffing, which get committed to the repo.

    https://github.com/ericfortis/mockaton/tree/main/pixaton-tes...

  • taspeotis 1 hour ago
    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
  • est 1 hour ago
    I maintain an internal wiki, the contents were generated by each CI/CD and always reflects from latest running code.
  • 3eb7988a1663 53 minutes ago
    shot-scraper is another project in this vein.

    https://github.com/simonw/shot-scraper

  • irishcoffee 35 minutes ago
    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.

  • immanuwell 18 hours ago
    nice, embedding the capture instructions right in the markdown as comments is a dead-simple solution that'll age way better than any fancy external tooling