Radiant Canvas and ComfyUI: what actually runs on the Mac

Following a text-to-image job through ComfyUI

A ComfyUI workflow is sent to the Python server as a prompt. The server does not treat it as a picture of a pipeline. It validates the nodes needed for the requested outputs and executes them.

For a small image workflow, the route usually looks something like this:

1. A loader opens a checkpoint or a set of separate model components.
2. Text is converted into conditioning by the encoder used by that model.
3. A latent image is created or loaded from an input image.
4. A sampler runs the denoising or flow steps.
5. A VAE decoder turns the resulting latent into pixels.
6. Preview and save nodes decide what becomes visible and what reaches disk.

Remove the VAE decoder and the graph no longer produces an ordinary image. Remove the save node and no file is written. Replace the sampler and you have changed the inference pipeline, not just a preference in the interface.

Execution begins at the output side. ComfyUI follows dependencies upstream, obtains the inputs for each node, then stores node outputs for later nodes. The current executor checks its output caches before it starts running the prompt.

That cache is one of the reasons the graph model works well for experiments. If an expensive upstream branch has not changed, its result may still be usable. Partial Execution narrows the target to one selected output, leaving unrelated output branches alone.

A complicated workflow can fork before decoding, feed the same image into several preprocessors, or keep a slow upscale branch separate from a fast preview. The graph is doing real work here. It is not merely recording settings.

The same job in Radiant Canvas

Radiant Canvas never builds the six-node chain described above. Pressing Generate creates a job for one of the app’s model-specific engines. That engine already contains the path from prompt encoding to decoded pixels.

The macOS application is written in Swift. Objective-C++ and C++ bridge into lower-level inference code where needed. Some models use MLX; others use a Metal-based path. ModelInferenceEngines selects the implementation associated with the installed model.

Because the model is known, the engine can own details that ComfyUI leaves in the graph or its loaders:

• the exact layout of the model components
• the text encoder and decoder paired with those weights
• supported sizes and model-specific generation modes
• compiled graphs, Metal streams, caches, and temporary allocations
• cancellation and cleanup for that implementation

Switching model families unloads the inactive engines. The MLX implementations release heavyweight model objects and clear allocator caches. This is handled by the application rather than represented by a node in the user’s document.

Studio sits above this layer. A generation node contains a model choice, prompts, seeds, dimensions, adapters, and supported image or mask inputs. Its wires connect pieces of a job. They do not carry the latent tensor being sampled inside the engine.

When Run is pressed, Studio first builds a plan. Prompt lists, model sets, seed sweeps, variations, and experiment matrices become rows. Five prompts across four seeds and three models make sixty rows; asking for two variations makes one hundred and twenty.

The plan is checked before it enters the queue. Missing inputs are reported, large run counts need confirmation, and the planner checks whether the output has enough free storage. A row that is accepted then follows the same inference path as a job from the Create screen.

Studio caches deterministic image operations by fingerprint. Generation stays in the normal queue, alongside cancellation, history, Gallery records, and model cleanup.

There is no latent socket hidden behind a Studio wire. A custom operation cannot be inserted halfway through the sampler. This is the architectural line between Studio and ComfyUI.

Model files are part of the workflow in ComfyUI

The graph only works if its loaders can find compatible files. ComfyUI separates common model types into directories, and the distinction is functional rather than cosmetic.

• models/checkpoints for packaged checkpoints
• models/diffusion_models for standalone diffusion or flow models
• models/clip for text encoders
• models/vae for image encoders and decoders
• models/loras and models/controlnet for auxiliary models

A valid file in the wrong directory may never appear in the expected loader. Recent releases also tend to split the pipeline across several downloads. The example workflow is often the clearest record of which encoder, VAE, and loader were used together.

Extra model paths let ComfyUI share a central collection with another installation or another application. This avoids duplicate weights, although the shared directory still needs to be mapped by model type.

Radiant Canvas replaces that directory layout with a manifest for each supported download. The manifest lists the files, expected sizes, and destination used by the engine. Model Manager keeps completed files after an interrupted download and requests the missing parts when the download resumes.

Quantization is fixed by the download. Krea 2 Q8 and Krea 2 INT4 ConvRot are separate installations. Selecting a smaller build does not reinterpret the Q8 files at runtime.

An arbitrary checkpoint cannot be dropped into Radiant Canvas. Supporting another architecture requires a downloader entry, an inference implementation, memory handling, settings, and an app update. ComfyUI can add support through Core or a custom node long before that work fits into a conventional application release.

Unified memory is still the hard limit

A Mac with 24 GB of unified memory has one 24 GB pool. macOS, the application, model weights, text encoders, intermediate tensors, and decoded images all use it. The GPU does not receive a second private allocation.

Radiant Canvas can plan around a known model layout. Inactive inference engines are unloaded when the family changes, and several MLX paths clear cached allocations between heavy stages. Model Manager shows a rough memory recommendation before installation.

ComfyUI has to manage whatever the graph requests. Core tracks loaded models and can offload components under pressure. After an out-of-memory error, the executor unloads the loaded models before the next run.

Offloading can make a large graph finish on a smaller machine. It also adds transfers. A run that keeps its model resident may be much faster than the same workflow after a small increase in resolution pushes part of the model out of memory.

Test the full job. Batch size, ControlNet, several adapters, and large output dimensions all change the result. A successful low-resolution sample proves that the files load; it does not prove that the planned batch fits.

Where the two applications stop overlapping

Custom nodes are the obvious dividing line. They are executable Python modules that can add loaders, samplers, preprocessors, API calls, interfaces, and new output types. They may also add dependencies and network behavior. ComfyUI recommends installing them only from authors you trust.

A custom-node environment needs maintenance. Package versions drift, Core changes, and old nodes can stop importing. ComfyUI Desktop helps by managing installation and allowing separate instances. Keeping a working project on a stable instance is often safer than updating every environment together.

Radiant Canvas has no custom-node system. Imported LoRAs and LoKrs modify supported model families inside the existing engines. They cannot introduce a loader, sampler, or media type.

Use ComfyUI when the job depends on any of the following:

• a model or quantization that Radiant Canvas does not support
• custom work between encoding, sampling, and decoding
• regional conditioning or adapter schedules built from community nodes
• API automation around a graph
• video, audio, or 3D pipelines

ComfyUI also has the more portable graph format. Workflows can be saved as JSON, and supported image files can carry workflow metadata. The graph can be restored from an old output if the required models and nodes are still installed.

That last condition matters. JSON does not contain the model weights, node repositories, or Python environment. Exact reproduction requires those pieces as well as the seed and graph.

Studio saves a `.radiantstudio` package with its graph and can carry imported assets, cached intermediate images, run plans, history, and result references. Gallery keeps generation settings beside the outputs. There is no converter between `.radiantstudio` and ComfyUI JSON.

Radiant Canvas is useful when the desired model is already supported and the work is prompt-to-image, comparison, or a planned batch. ComfyUI remains the better tool when the graph itself is part of the work.

Both can run locally. ComfyUI Core can work offline and API nodes can be disabled, although installed custom nodes need their own review. Radiant Canvas has no account, analytics, developer telemetry, or cloud generation service. It uses the network for model downloads, App Store purchases, and the optional Apple enhancement model.