DEV Community: John Wick

1 Process vs 3, 98 MB vs 324 MB: A Live Wallpaper Showdown on Windows

John Wick — Fri, 13 Nov 2026 15:21:24 +0000

Disclosure: I'm the developer of EWRE.

I played the same 1080p, 60 FPS H.264 video as a wallpaper in two engines on the same Windows 11 machine (GTX 1080 Ti) and sampled resource use every second for 30 seconds.

	EWRE	Lively v20262.5.6
Processes	1	3
Avg CPU	2.65%	6.46%
Peak CPU	9.30%	18.70%
Avg RAM	98.7 MB	324.3 MB

The takeaway: EWRE used about 59% less CPU and about 70% less RAM in this test. It's a single native process (Direct3D 11 + Media Foundation with hardware decoding), while Lively runs a .NET/WinUI app plus an mpv player process.

The fine print: one machine, one clip, one 30-second run. GPU and VRAM weren't measured, and RAM is working set summed across processes. Treat it as one data point, not a final verdict.

EWRE is free on the Microsoft Store. Run your own test and tell me what you get. 👇

I Benchmarked My Live Wallpaper Engine Against Lively: 59% Less CPU, 70% Less RAM (and What I Didn't Measure)

John Wick — Fri, 13 Nov 2026 15:20:30 +0000

Disclosure: I'm the developer of EWRE, so I have an obvious bias. I'm sharing the setup, the raw numbers, and the limits of the test so you can judge them yourself.

The question

A live wallpaper runs all day and nobody stares at it. So how much should it cost? I compared EWRE (my engine) with Lively Wallpaper, a popular free one, playing the same video on the same machine.

Test setup


OS	Windows 11
GPU	NVIDIA GeForce GTX 1080 Ti (driver 582.28)
Video	`dem.mp4`, 1920x1080 @ ~60 FPS, H.264
Method	Sampled every 1 s for 30 s of continuous desktop playback
Versions	EWRE (current build) vs Lively v20262.5.6

How they're built

EWRE: one native process (C++20, Direct3D 11, Media Foundation). Playback happens in-process, with hardware decoding.
Lively: C# on .NET 9 with WinUI 3. Video is played by an mpv.exe child process. During the test I measured three processes: Lively.exe, mpv.exe, and Lively.Watchdog.exe.

Results

Metric	EWRE	Lively	Difference
Processes	1	3
Average CPU	2.65%	6.46%	59.0% lower
Peak CPU (1 s sample)	9.30%	18.70%	50.3% lower
Average RAM (working set)	98.70 MB	324.29 MB	69.6% lower (about 226 MB)
Peak RAM (working set)	101.16 MB	331.71 MB	69.5% lower

Where Lively's resources go

Process	RAM	CPU
`Lively.exe`	~157 MB	mostly 0 to 2%
`mpv.exe`	~146 to 159 MB	most of the CPU, with bursts up to 18.7%
`Lively.Watchdog.exe`	~15.5 MB	~0%

Lively's CPU wasn't evenly spread. There were two sustained bursts of 15 to 19% (around seconds 18 to 22 and 28 to 29), almost entirely from mpv.exe. EWRE's worst single sample was 9.3%.

Why might EWRE be lighter?

I didn't profile this, so these are hypotheses based on the architecture:

No IPC. Playback is in-process, with no separate player to coordinate with.
No managed runtime. Native code means no .NET or WinUI footprint.
Hardware decoding straight into GPU textures through Direct3D 11 and Media Foundation, which keeps CPU work low.

What this test does NOT show

I'd rather you hear this from me:

One run, one machine, one video, 30 seconds. Treat it as a data point, not a verdict. Longer runs and other hardware could look different.
GPU and VRAM usage weren't measured. Hardware decoding moves work to the GPU, so a full comparison needs GPU load, VRAM, and ideally power draw.
RAM is working set, summed across Lively's processes. That can overcount pages shared between them, so the real difference may be smaller than 226 MB.
CPU samples are coarse. Values move in steps of about 1.56%, which matches Windows' 15.6 ms CPU-time tick over a 1 s window, so small differences are noise.
Lively's player settings matter. [State here whether Lively ran on default settings and whether mpv hardware decoding was enabled.]
30 seconds can't prove there are no memory leaks. EWRE's RAM stayed between about 93 and 101 MB, but a proper leak test needs hours.
Lively does more than play video. This only compares video playback.

Reproduce it

The raw per-second data for both engines is on GitHub: [link to benchmark folder]. If you run the same test on different hardware, I'd really like to see your numbers.

Try it

EWRE is free on the Microsoft Store. Feedback and bug reports are welcome on GitHub.

What would you want measured next: GPU usage, battery drain, or a long-session leak test? 👇

Show DEV: EWRE, a Lightweight Live Wallpaper Engine for Windows

John Wick — Sat, 07 Nov 2026 19:44:49 +0000

What I built

EWRE (Elite Wallpaper Rendering Engine) is a free live video wallpaper engine for Windows 10 and 11. It plays a video behind your desktop icons and tries to cost as little as possible while doing it.

📥 Get it on the Microsoft Store
💻 GitHub: StayElite

Why I built it

[Write 2 to 4 sentences here. What annoyed you about existing live wallpaper apps? A real reason, like "my laptop fan spun up" or "my game stuttered", is more convincing than anything generic.]

What it does

GPU-accelerated rendering through Direct3D 11
Hardware decoding via Media Foundation (NV12 and RGB32)
60+ FPS playback with no screen tearing
Multi-monitor support: a separate wallpaper per display, or one spanning all of them
Smart pause: rendering suspends when a fullscreen game launches, when the laptop is on battery, when the PC is locked, or when displays power down
Formats: MP4, MKV, WebM, MOV, AVI and more

The design principle

Everything in EWRE follows one rule: the cheapest frame is the one you never render. A wallpaper is background decoration, so it should yield to whatever you're actually doing. That's why the pause conditions matter as much as the rendering pipeline.

What was hard

[Share one or two real challenges. Ideas: attaching to the desktop layer, handling multiple monitors with different resolutions, behavior across Windows versions, keeping memory stable over long sessions. Pick what's true for you.]

Performance

[If you have numbers, put them here: CPU and GPU usage while playing a 1080p or 4K clip, memory use, and battery impact. Even a single screenshot of Task Manager helps. If you don't have measurements yet, delete this section rather than guessing.]

What I'd like feedback on

Does it behave well on your hardware? Tell me your GPU and Windows version if something breaks.
Which features are missing for your setup?
Are there video formats or codecs that give you trouble?

What's next

[List 2 or 3 planned features, only the ones you actually intend to build.]

Try it

EWRE is free: Microsoft Store.

If you try it, I'd like to hear how it goes in the comments. Bug reports and ideas are welcome on GitHub. 👇

How Does a Live Wallpaper Draw Behind Your Desktop Icons on Windows?

John Wick — Sat, 07 Nov 2026 19:42:56 +0000

Live wallpaper apps like EWRE play a video behind your desktop icons, but in front of the static wallpaper. Windows has no public API for that. So how is it done?

This post explains the well-known technique that wallpaper engines use. It relies on undocumented shell behavior, so treat it as a field guide rather than a contract.

The desktop is made of windows

Your desktop is a stack of ordinary windows owned by Explorer:

Progman: the Program Manager window, the root of the desktop.
SHELLDLL_DefView: the window that draws your icons.
WorkerW: a helper window. The static wallpaper is painted into one of these.

The goal is to place your own window behind the icons (SHELLDLL_DefView) and in front of the static wallpaper.

Step 1: Ask Progman to create a WorkerW

Sending Progman an undocumented message, 0x052C, makes it spawn a WorkerW window sitting behind the icon layer.

HWND progman = FindWindowW(L"Progman", nullptr);
SendMessageTimeoutW(progman, 0x052C, 0, 0, SMTO_NORMAL, 1000, nullptr);

Step 2: Find the right WorkerW

After that message, there are several WorkerW windows. The one you want is the sibling that comes after the WorkerW that contains SHELLDLL_DefView.

#include <windows.h>

static HWND g_workerw = nullptr;

BOOL CALLBACK EnumProc(HWND hwnd, LPARAM) {
    HWND defView = FindWindowExW(hwnd, nullptr, L"SHELLDLL_DefView", nullptr);
    if (defView) {
        g_workerw = FindWindowExW(nullptr, hwnd, L"WorkerW", nullptr);
    }
    return TRUE;
}

HWND GetWallpaperHost() {
    HWND progman = FindWindowW(L"Progman", nullptr);
    SendMessageTimeoutW(progman, 0x052C, 0, 0, SMTO_NORMAL, 1000, nullptr);
    EnumWindows(EnumProc, 0);
    return g_workerw;
}

Step 3: Parent your window to it

Once you have the handle, make your rendering window a child of it:

HWND host = GetWallpaperHost();
if (host) {
    SetParent(myWindow, host);
    // Resize myWindow to cover the monitor
}

Your Direct3D swap chain, or any renderer, now draws into a window that sits between the icons and the static wallpaper. A video player on top of this is a live wallpaper.

What the renderer does next

The window trick only places the surface. The actual playback is a separate problem. EWRE, for example, uses Direct3D 11 rendering with Media Foundation and hardware decoding, and supports multi-monitor setups either with independent wallpapers or spanning. See my other post on why that pipeline keeps overhead low.

Gotchas

Windows versions differ. The shell's window hierarchy has changed over time, and newer Windows 11 builds behave differently from older ones (for example, where the WorkerW ends up in the tree). Test on every version you support instead of trusting one snippet.
Explorer restarts. If Explorer crashes or restarts, the host window disappears. A robust engine watches for that and re-attaches.
Multiple monitors and DPI. Size your window using the virtual desktop bounds, and handle per-monitor DPI.
Undocumented behavior. Microsoft can change this at any time. Keep the code isolated so it's easy to patch.
Be a good citizen. Pause rendering when the desktop isn't visible, such as a fullscreen game, a locked PC, or displays off. EWRE does exactly this, plus pausing on battery power.

Wrap up

A live wallpaper is just a window with a clever parent. The hard parts are everything around it: decoding efficiently, handling monitors, and knowing when to stop drawing.

If you want to see the result, EWRE is free on the Microsoft Store. Developer: github.com/StayElite.

Have you worked with the Progman/WorkerW approach? Share your experience in the comments. 👇

Prepare Your Own Video Wallpaper with FFmpeg (and Run It with EWRE on Windows)

John Wick — Sat, 07 Nov 2026 19:41:33 +0000

Live wallpaper engines can play most video files as they are. But a raw 4K movie clip with a stereo audio track is not the ideal wallpaper. It's bigger than it needs to be, it may stutter on weaker hardware, and it probably doesn't loop cleanly.

A few FFmpeg commands fix all of that. In this post I'll prepare a clip for use with EWRE, a free live wallpaper engine for Windows 10 and 11 that plays MP4, MKV, WebM, MOV, AVI and more.

You don't need to convert anything for EWRE to work. This is optional tuning for smaller files and a cleaner result.

What makes a good wallpaper clip

Short. 5 to 20 seconds is plenty for a loop.
No audio. A wallpaper doesn't need a sound track.
Right resolution. Match your monitor, not more.
Compatible pixel format. 8-bit 4:2:0 is the safest choice for hardware decoders.
Loop-friendly. The end should lead back to the start without a jarring jump.

1. Trim the clip

Cut a 10-second section starting at 5 seconds:

ffmpeg -ss 00:00:05 -i input.mp4 -t 10 -c copy trimmed.mp4

-c copy is instant because it doesn't re-encode, but it cuts at keyframes, so the start can be slightly off. If you need exact cuts, drop -c copy and let the next step re-encode.

2. Resize, remove audio, and set a compatible format

ffmpeg -i trimmed.mp4 \
  -vf "scale=1920:-2" \
  -c:v libx264 -crf 20 -preset slow \
  -pix_fmt yuv420p \
  -an \
  -movflags +faststart \
  wallpaper.mp4

What each part does:

Option	Purpose
`scale=1920:-2`	Resize to 1920 wide, keep the aspect ratio, keep height even
`-c:v libx264`	Encode with H.264, which hardware decoders handle widely
`-crf 20`	Quality level. Lower is better quality and a bigger file
`-preset slow`	Better compression for the same quality
`-pix_fmt yuv420p`	8-bit 4:2:0, the most compatible format
`-an`	Strip the audio track
`-movflags +faststart`	Moves metadata to the front of the file

For a 1440p or 4K monitor, change 1920 to 2560 or 3840.

3. Reduce the frame rate if you want a lighter file

If the source is 60 FPS and you'd rather save space and decoding work:

ffmpeg -i wallpaper.mp4 -vf "fps=30" -c:v libx264 -crf 20 -pix_fmt yuv420p -an wallpaper_30fps.mp4

Don't use fps=60 on a 30 FPS source. It only duplicates frames and makes the file bigger without making it smoother.

4. Make a loop-friendly clip

If the end of your clip doesn't match the start, the loop point will show. A simple trick is a "boomerang": play the clip forward, then backward.

ffmpeg -i wallpaper.mp4 \
  -filter_complex "[0:v]reverse[r];[0:v][r]concat=n=2:v=1:a=0" \
  -c:v libx264 -crf 20 -pix_fmt yuv420p \
  boomerang.mp4

The reverse filter loads the whole clip into memory, so keep the input short (a few seconds). It works best for slow, ambient footage like clouds, water, or particles. It looks odd with anything that has obvious direction, like text or walking people.

5. Check the result

ffprobe -v error -show_entries stream=codec_name,width,height,r_frame_rate,pix_fmt -of default=nw=1 wallpaper.mp4

You should see h264, your target resolution, the frame rate you chose, and yuv420p.

6. Set it as your wallpaper

Install EWRE from the Microsoft Store.
Select your processed file.
Assign it to one monitor, or span it across all of them.

EWRE pauses automatically when a fullscreen game launches, when you're on battery, when the PC is locked, or when displays power down, so a lean clip plus smart pausing keeps the overhead low.

Batch tip

To process a whole folder of clips from PowerShell:

Get-ChildItem *.mp4 | ForEach-Object {
  ffmpeg -i $_.FullName -vf "scale=1920:-2" -c:v libx264 -crf 20 -pix_fmt yuv420p -an "wall_$($_.Name)"
}

Wrap up

Trim it, resize it, strip the audio, and make the loop clean. Five minutes of FFmpeg work gives you a smaller file and a better-looking desktop.

Got a favorite FFmpeg one-liner for wallpapers? Drop it in the comments. 👇

EWRE: EWRE - Live Desktop Wallpaper · Developer: github.com/StayElite

5 Things to Check Before Installing a Live Wallpaper on Windows

John Wick — Sat, 07 Nov 2026 19:40:32 +0000

An animated desktop looks great for the first ten minutes. After that, the questions start: why is my fan louder, why did my battery drop so fast, why is my game stuttering?

Before you install any live wallpaper engine, run it through this checklist.

1. Does it pause when you game?

This is the most important one. A wallpaper that keeps rendering behind a fullscreen game is drawing frames nobody can see and competing with the game for your GPU.

Look for an engine that suspends rendering automatically when a fullscreen app launches. EWRE does this, so you don't have to remember to turn the wallpaper off before a session.

2. What happens on battery?

On a laptop, a looping video can quietly cost you battery life. A good engine should stop rendering when you unplug.

EWRE pauses on battery power. It also pauses when the PC is locked or when the displays power down, which are other moments when nobody is looking at the desktop.

3. Does it use hardware decoding?

Decoding video on the CPU is expensive. Decoding it on the GPU's dedicated video hardware is much cheaper.

Check whether the engine mentions hardware decoding. EWRE uses Media Foundation with hardware decoding support (NV12 and RGB32) and renders through Direct3D 11, which is the kind of pipeline you want for smooth 60+ FPS playback without tearing.

4. How does it handle multiple monitors?

If you run more than one display, check two things:

Can you set a different wallpaper on each monitor?
Can you span one wallpaper across all of them?

EWRE supports both modes, so you can pick whichever suits your setup.

5. Will it play the videos you already have?

Some engines make you convert files before you can use them. That's a pain if you've already downloaded a few favorites.

EWRE plays MP4, MKV, WebM, MOV, AVI and more, so most files work as they are.

Quick scorecard

Check	What to look for	EWRE
Pauses for games	Auto-suspends on fullscreen	✅
Battery friendly	Pauses on battery power	✅
Hardware decoding	GPU-accelerated	✅
Multi-monitor	Per-display or spanning	✅
Format support	MP4, MKV, WebM, MOV, AVI and more	✅
Price	Free	✅

Try it

EWRE is free on the Microsoft Store for Windows 10 and 11: EWRE - Live Desktop Wallpaper.

What's on your desktop right now? Share your setup in the comments. 👇

What Makes a Live Wallpaper Engine "Lightweight"? Direct3D 11, Hardware Decoding, and Knowing When to Stop

John Wick — Sat, 07 Nov 2026 19:39:18 +0000

A live wallpaper is a video player that never gets a window of its own. It runs all day, behind everything else, and nobody is watching it most of the time. That makes it a good case study in resource discipline: the cheapest frame is the one you never render.

Here's how a lightweight live wallpaper engine approaches the problem, using EWRE (Elite Wallpaper Rendering Engine) as the example. EWRE is a free live video wallpaper engine for Windows 10 and 11, available on the Microsoft Store.

Idea 1: Let the GPU do the decoding

Video decoding in software is expensive, and the cost scales with resolution and frame rate. A 4K, 60 FPS wallpaper decoded on the CPU would be noticeable in any task manager.

EWRE uses Media Foundation for decoding, with full hardware decoding support. Modern GPUs have dedicated video decode blocks, so the work moves off the CPU entirely. EWRE handles two frame formats from the decoder:

NV12: the common planar YUV format that hardware decoders output natively
RGB32: a straightforward 32-bit RGB format

Supporting the decoder's native output format matters because it avoids extra conversion passes before the frame reaches the screen.

Idea 2: Keep the render path short

Once a frame is decoded, it has to be drawn. EWRE renders through a Direct3D 11 pipeline with hardware acceleration. Decoded frames can stay on the GPU and go straight to the display, instead of being copied back and forth between system memory and video memory.

The result, according to the listing, is smooth playback at 60+ FPS with no screen tearing, rendered directly behind your desktop icons.

Idea 3: The best optimization is to stop

Fast decoding and a short render path only get you so far. A wallpaper that renders at full speed behind a fullscreen game is still wasting power on pixels nobody can see.

EWRE's biggest efficiency win is a set of conditions where it suspends rendering:

Condition	Why pausing makes sense
Fullscreen game launches	The wallpaper is completely covered, and the game needs the GPU
Running on battery	Saves power when it matters most
PC locked	Nobody is looking at the desktop
Displays power down	There's nothing to draw on

This is the same principle as pausing a browser tab's animations when the tab is hidden. If the output isn't visible, don't produce it.

Multi-monitor as a design constraint

Multiple displays complicate a wallpaper engine. Each monitor can have a different resolution and refresh rate, and a single video might need to be spread across all of them. EWRE supports both modes:

Independent wallpapers on each connected display
Spanning one wallpaper across the whole setup

Format support

The engine plays MP4, MKV, WebM, MOV, AVI and more. Using the system's media stack means you can use video files you already have without converting them first.

Takeaways for your own projects

If you're building anything that runs continuously in the background, three rules apply:

Use the hardware that exists. Dedicated decode blocks beat software decoding.
Keep data where it is. Avoid copying frames between CPU and GPU memory.
Detect when your output is invisible and stop. This is often the largest saving of the three.

Try it

EWRE is free on the Microsoft Store: EWRE - Live Desktop Wallpaper. The developer is on GitHub at github.com/StayElite.

If you've built something similar, or have opinions on the best way to keep a background renderer cheap, I'd like to hear about it in the comments.

I Got Tired of Heavy Live Wallpaper Apps, So Here's a Lightweight One Built on Direct3D 11

John Wick — Sat, 07 Nov 2026 19:37:39 +0000

Live wallpapers look great, but most engines eat CPU and GPU and drain your laptop battery while you're trying to work or game.

EWRE (Elite Wallpaper Rendering Engine) is a lightweight live video wallpaper engine built natively for Windows 10 and 11. It's free on the Microsoft Store.

What it does

EWRE plays a video file as your desktop background, rendered behind your icons. That's the whole idea, and it's built to do it with minimal overhead.

Under the hood

The rendering pipeline is built on two Windows-native pieces:

Direct3D 11 handles the rendering.
Media Foundation decodes the video, with full hardware decoding support for NV12 and RGB32 frame formats.

Decoding on the GPU instead of the CPU keeps playback smooth at 60+ FPS without screen tearing, and leaves your processor free for real work.

Features

Multi-monitor support

Set a different wallpaper on each display, or span a single video across your whole setup.

Smart pause

The engine suspends rendering when it would only waste resources:

You launch a fullscreen game
Your laptop is running on battery
The PC is locked
The displays power down

If you game, this is the feature that matters. The wallpaper doesn't compete with your frame rate.

Wide format support

MP4, MKV, WebM, MOV, AVI and more. Use whatever video you already have, with no conversion step.

Who it's for

Casual users who want a more alive desktop without slowing the machine down
Gamers who want the wallpaper to get out of the way automatically
Laptop users who care about battery life
Multi-monitor setups that deserve more than one stretched image

Try it

Install it from the Microsoft Store:

👉 EWRE - Live Desktop Wallpaper

The developer is on GitHub: github.com/StayElite. Feedback and bug reports are welcome in the comments below.

What's your go-to live wallpaper setup? Let me know. 👇

A Local-First VS Code Extension: No Git, No Telemetry, No Network, and It Works in Codespaces

John Wick — Fri, 30 Oct 2026 06:23:24 +0000

| SavePoint Diff runs entirely inside the extension host, so it works across local, SSH, WSL, containers, Codespaces, and vscode.dev.

Plenty of dev tools want an account, a network call, or a telemetry opt-out. I wanted the opposite for SavePoint Diff.

What "100% local" means here

Everything runs inside the VS Code extension host
No Git required
No telemetry
No network requests
No external services
The baseline is held in memory for the current window session and never touches disk

The only requirement is VS Code 1.60.0 or later.

Works where you work

Because there are no external dependencies, it behaves the same across:

Local folders
Remote-SSH
WSL
Dev Containers
GitHub Codespaces
Virtual filesystems like vscode.dev and github.dev

Make it yours

Everything is toggleable in settings:

{
  "savepointDiff.showAdded": true,
  "savepointDiff.showModified": true,
  "savepointDiff.showDeleted": true,
  "savepointDiff.showOverviewRuler": true,
  "savepointDiff.showBackgroundHighlight": false,
  "savepointDiff.enableRevertInHover": true
}

Prefer a subtle gutter only? Leave highlighting off. Want changed lines tinted too? Set showBackgroundHighlight to true. There's also a one-click status bar toggle (SavePoint: ON / OFF) if you want it out of the way temporarily.

Good to know

In Git repositories, VS Code's own editor-gutter "quick diff" colors are typically driven by Git's provider. SavePoint Diff's panel entry, badges, and diff view work independently alongside it, in Git and non-Git folders alike.

Try it

ext install StayElite.StayElite-Savepoint-Diff

GitHub · MIT licensed · feedback and issues welcome.

How a Live Unsaved-Changes Diff Works in a VS Code Extension

John Wick — Fri, 30 Oct 2026 06:22:28 +0000

| Baselines, Myers line diffs, debouncing, undo/redo, and the edge cases behind SavePoint Diff's gutter markers.

I recently shipped SavePoint Diff, a VS Code extension that shows gutter markers for unsaved changes. Here's the design, in case you're thinking about building something similar.

The core idea: a baseline

Everything revolves around one string per file, the baseline, meaning the last saved content.

File opens: capture its content as the baseline.
Edit: diff baseline against the current buffer, then render the result as gutter decorations.
Save: the baseline becomes the new content, and the markers clear.

The diff itself uses a small, well-established Myers line-diff library rather than anything custom.

Debouncing

Diffing on every keystroke is wasteful, so recalculation is delayed until typing pauses. The delay is configurable:

"savepointDiff.debounceMs": 150

Files above a size threshold skip live diffing entirely to protect performance (savepointDiff.maxFileSize, default 2,000,000 bytes).

Why undo/redo is free

Instead of tracking edits incrementally, the diff is always recomputed from baseline vs. current text. That means undo back to the saved state yields an empty diff, so markers vanish, and redo brings them back. There's no delta bookkeeping to corrupt.

Edge cases that bit me

The changelog lists a lot of these, but the interesting ones were:

CRLF and lone CR line endings need normalizing, or the diff lies.
Multi-change reverts: applying several edits must go in descending order, or earlier edits shift the ranges of later ones.
Revert File / external rewrites: if the file stops being dirty without a save, its content now matches disk, so the baseline re-syncs automatically.
Invalid settings: a bad maxFileSize (zero, negative, non-numeric) used to be able to silently disable diffing. It now falls back to the default.
Stale badges on hidden tabs needed explicit handling.

Savepoints are just a baseline move

The manual savepoint feature falls out of the design. It moves the baseline to the current in-memory content without writing to disk. No new machinery needed.

Takeaway

Recompute from two strings, resist clever incremental state, and spend your effort on the edge cases. The code is MIT licensed if you want to read it or contribute.

GitHub · Marketplace

Local File History for VS Code: Git-Style Snapshots Without Git

John Wick — Fri, 30 Oct 2026 06:21:08 +0000

| Named checkpoints, automatic snapshots on save, split-diff comparison, and one-click restore, per file, entirely local.

Sometimes you don't need a repo. You need a quick way to say "take me back to how this file looked an hour ago."

SavePoint Diff includes snapshot history for exactly that.

How snapshots work

Manual checkpoints:

SavePoint Diff: Save Snapshot

Automatic snapshots: by default, a snapshot is captured every time you save a file.

Browse and restore:

SavePoint Diff: View & Restore Snapshot...

This opens the timeline for the active file. Pick any snapshot and you can:

open a split diff of that snapshot against your current buffer
revert the entire file to it with one click

Tuning it

Add these to settings.json:

{
  "savepointDiff.snapshots.enabled": true,
  "savepointDiff.snapshots.maxSnapshots": 10,
  "savepointDiff.snapshots.autoSnapshotOnSave": true
}

The defaults keep up to 10 snapshots per file, so history stays small. Raise the number if you want a longer timeline, or turn off auto-snapshots and only create named ones when it matters.

When this is handy

Experimenting in a scratch folder with no version control
Editing config files you'd rather not commit
Hand-tweaking generated code
Working in a repo but wanting finer-grained undo than commits give you

Keep expectations realistic

This is per-file local history, not a replacement for Git. There's no branching, merging, or remote. It's a lightweight safety net for the moments Git doesn't cover.

Marketplace · GitHub

Make a Savepoint Before Your Risky Refactor (Without Saving to Disk)

John Wick — Fri, 30 Oct 2026 06:20:05 +0000

| How SavePoint Diff's manual savepoints let you diff against "five minutes ago" instead of "my last Ctrl+S".

You're about to do something scary to a file. Rename a core function, restructure a module, rewrite a hot loop.

You don't want to save yet, because the half-finished state might trip a file watcher, a hot-reloader, or a formatter-on-save. But you also don't want to lose your current good-ish state.

Manual savepoints

SavePoint Diff has a command for exactly this:

SavePoint Diff: Create Savepoint (Don't Save to Disk)

It snapshots the active file's current in-memory content as the new diff baseline. Nothing is written to disk. From that moment, the gutter markers and diff view show what you've changed since the savepoint.

A workflow

Your file is in a decent state, unsaved.
Run Create Savepoint.
Start the risky refactor and watch the gutter track every change since the savepoint.
Open the split diff to review, or hover a marker and click ↺ Revert this change to undo one block.
When you're happy, save normally. The baseline moves again.

One thing to know

After a savepoint, SavePoint Diff's surfaces (panel entry, "M" badge, status bar count) show "no differences", because the baseline now matches your buffer. But your file still has unsaved edits on disk terms.

So once you've used a savepoint, trust the editor tab's own ● dirty dot to tell you whether you still need to press Ctrl+S. This is documented in the README's known limitations, and it's worth knowing so it doesn't surprise you.

Want durable checkpoints instead?

There's a second feature for that: named snapshots you can restore later. I cover it in the next post.

Install SavePoint Diff