Performance and hardware
The application uses your graphics card. The batch tool does not. That sounds like a gap and mostly is not one, and this page explains both halves so you can tell whether something is slow for a reason.
The GPU is used in the application, not in the batch tool
In the editor, the work is done on your graphics card when one is available. The status bar says GPU or CPU for every solve, so you never have to guess which you got.
In tnmap, the batch tool, everything runs on the CPU. That is a real limitation and it is stated plainly rather than
buried, but it matters less than it first appears.
The reason is what the GPU is actually buying. Its advantage here is latency — it exists so that dragging a slider feels live, so that the picture keeps up with your hand. A batch of two hundred sprites is a throughput problem, and nobody is watching it happen. A CPU batch run is slower per sprite and finishes while you do something else.
There is a second, more practical reason: a self-contained executable with no runtime to install cannot easily carry a graphics stack with it. Given a choice between "runs anywhere with nothing installed" and "runs faster on machines with the right drivers", the batch tool takes the first.
If batch throughput becomes the thing standing between you and shipping, that is worth telling us. It is a solvable problem and the reason it is not solved is that latency was the pressing one.
When the editor falls back to the CPU
Capability is detected rather than assumed. If your graphics card cannot be used, the editor uses the CPU and says so in two places: CPU in the status bar, and a line in the inspector's Solve detail section explaining why.
That second part is the one that matters, because "why" is usually actionable. Common causes are a browser or webview without a working graphics backend, a driver that declines the request, or a machine with no discrete graphics at all.
The result is identical either way. The CPU path and the GPU path produce the same normal map — they are held to that deliberately, because two plausible normal maps that disagree is a far worse failure than a slow one.
Live updates, and when they switch themselves off
By default the result updates as you work: as you drag a slider, as you paint a stroke.
On a large sprite with expensive settings, a solve can take long enough that live updating stops being helpful and starts being in the way. When that happens the editor notices:
- A solve takes longer than about 0.8 seconds → live updating switches off, an Update button appears, and the inspector says why.
- Solves come back under about a quarter of a second again → live updating switches itself back on.
Both directions are automatic, with a deliberate gap between the two thresholds so it cannot oscillate. You can also switch live updating off yourself with the Update live checkbox in the options bar, and it will stay off.
Drafts
While you are dragging something, the editor may show a draft — a lower-quality approximation, computed quickly, replaced by the full result when you stop. The inspector's Solve detail section reports which you are looking at.
Drafts are for keeping the picture attached to your hand. A draft cannot be exported, and the export command is unavailable while one is showing.
What makes a solve expensive
Roughly in order of impact:
- Sprite size. Cost scales with the pixel count, so a 1024-square sheet is far more than four times a 512-square one in practice.
- Follow overall form. On, the overall shape has to be worked out before the detail is laid over it. Off, that work disappears.
- Detail methods. Each one with a weight above zero is extra work. They are cached per sprite, so changing a weight is much cheaper than switching a method on.
- Painted hints are cheap. Paint freely.
The first solve of a session
The first solve after opening the application is slower than the ones after it — the graphics pipeline has to be prepared before anything can run on it, and that is a fixed cost paid once. It is deliberately started before you have opened a sprite, so most of it overlaps with the application loading.
You may also see one unusually slow solve after leaving the application idle for a while. That is your graphics card having dropped to a low clock speed while nothing was asking anything of it, and it recovers on its own within a solve or two.
What the packaged application is
The desktop build uses your operating system's own web view rather than bundling a browser: WebView2 on Windows, and the system equivalent elsewhere. That keeps the download small and means security updates arrive through the operating system rather than waiting for a release here.
It is a desktop application, not a browser tab. There is no address bar, and it does not need a network connection — nothing about your artwork leaves your machine.