Iris: Digital Pathology Rendering Engine

• Iris is a digital pathology rendering engine that leverages C++/Vulkan and rapid tile buffering to deliver real-time, high-resolution slide navigation.
• It employs stateless CPU threads with explicit GPU synchronization for lock-free, concurrent processing, achieving sub-refresh field updates.
• Iris integrates single-pass mipmap enhancement and cache-centric VRAM management, significantly outperforming conventional whole-slide imaging viewers.

Iris is a digital pathology rendering system introduced as a high-performance alternative to conventional whole-slide imaging viewers, with Iris Core denoting its core rendering engine technology. It was developed in response to a specific bottleneck in digital pathology: although whole slide imaging promises numerous advantages, adoption is limited by challenges in ease of use and speed of high-quality image rendering relative to the simplicity and visual quality of glass slides. In "Iris: A Next Generation Digital Pathology Rendering Engine" (Landvater et al., 21 Apr 2025), Iris Core is presented as a C++/Vulkan engine built around novel rapid tile buffering algorithms, stateless isolation of core processes, explicit synchronization of GPU work, and high-throughput rendering pipelines designed for real-time slide navigation.

1. Functional scope and design objective

Iris Core is written from the ground up in portable C++ machine-code modules and is compiled for Windows, macOS, iOS and Linux, with minimal dependencies restricted to libPNG, TurboJPEG, and FreeType (Landvater et al., 21 Apr 2025). Its architectural premise is that digital pathology viewing should approach the responsiveness and continuity associated with direct glass-slide examination. The engine therefore focuses on the rendering path itself rather than on conventional viewer abstractions.

The system is built on Vulkan, described as a low-level, low-overhead cross-platform GPU application program interface. Within Iris Core, Vulkan is used to gain explicit control over command queues, memory and cache, rather than delegating those decisions to higher-level graphics middleware. This design choice is central to the engine’s stated behavior: rendering, transfer, and compute are treated as separately orchestrated but concurrently active subsystems.

A defining operational target is rapid replacement of the visible field of view. Iris Core buffers an entire new slide field of view without overlapping pixels in 10 ms, with enhanced detail in 30 ms, and achieves slide rendering at the sustained maximum frame rate on all tested platforms (Landvater et al., 21 Apr 2025). This framing situates Iris not simply as a viewer, but as a rendering engine optimized for gigapixel pathology workloads, particularly where panning, zooming, and low-latency rebuffering are dominant constraints.

2. Stateless concurrency and process isolation

Iris Core’s CPU processes are described as “stateless” relative to one another: each thread maintains its own view-model and never blocks waiting on others (Landvater et al., 21 Apr 2025). Interprocess coordination is performed by atomic flags and non-blocking signals in a “pull” architecture. This means that work is not serialized through a central blocking controller; instead, each thread re-computes its own work queue when atomically signaled that the view state has changed.

Four primary CPU thread types are defined: the rendering thread, which issues scope-view draw commands; the buffering thread, which manages hierarchical transfer and compute queues; image-loader threads, which read and decompress tiles from the whole-slide image file or short-term RAM cache; and callback or event threads, which handle housekeeping and GPU-to-CPU notifications. All API calls are thread-safe, and updates such as pan and zoom arrive via UI threads that atomically signal the other threads to re-compute their own work queues (Landvater et al., 21 Apr 2025).

Interprocess communication is organized around two shared resource directories. The first is a GPU-Resource Map, which hashes $$(\text{tile\_x}, \text{tile\_y}, \text{resolution})$$ to VRAM allocation indices. The second is a short-term image cache in host RAM containing recently decompressed tiles, specifically a 1–3-tile perimeter outside the current view. The paper emphasizes that this design operates without locking: loader threads fill the RAM cache, the buffering thread pulls available images, and the rendering thread pulls fully buffered textures (Landvater et al., 21 Apr 2025).

This arrangement suggests a deliberate rejection of conventional blocking producer-consumer pipelines. A plausible implication is that Iris treats synchronization overhead itself as a first-order performance problem, not merely the volume of slide data.

3. Rapid Tile Buffering Sequence

The engine’s principal algorithmic contribution is the Rapid Tile Buffering Sequence, or RTBS, described as a hierarchically prioritized, super-pipelined microtransactional buffering method (Landvater et al., 21 Apr 2025). On each pass, the buffering thread recalculates the exact set of tiles within “view + perimeter,” filters out tiles that are already buffered or already in flight, and then submits a small batch of immediately available, unbuffered tiles as one atomic microtransaction.

Because hundreds of microtransactions may be enqueued across frames, Vulkan’s scheduler can interleave transfer and compute across physical cores without waiting on upstream processes. The paper characterizes this as “super-pipelining”: fragmenting buffering into tiny, high-priority chunks reduces per-tile buffering time as more tiles are in flight (Landvater et al., 21 Apr 2025). Empirically, the microtransaction batch size $M$ is tuned so that per-tile latency remains approximately $100\ \mu s$ under load. In the paper’s complexity description, each BufferPass is $O(V)$ for filtering and then $O(\min(V,M))$ for submissions, where $V$ is the number of tiles in view.

The buffering thread issues three commands per tile microtransaction: transfer from staging memory to GPU-local VRAM, a single-pass downsample compute dispatch, and a metadata flag marking the tile “visible” in that resolution layer (Landvater et al., 21 Apr 2025). Because Vulkan exposes independent transfer, compute and render queue families, Iris submits to all three concurrently. The design therefore treats a tile not as a monolithic unit of work, but as a compact sequence of transfer, compute, and visibility-state transitions.

This microtransaction model is directly tied to the reported performance metrics. The paper states that the system buffers an entirely new field of view in less than a single monitor refresh on a standard display, with high-detail features appearing within 2–3 monitor refresh frames (Landvater et al., 21 Apr 2025).

4. Single-pass reduction-enhancement and multi-resolution rendering

A second core technique in Iris Core is its single-pass reduction-enhancement pipeline for multi-resolution tile generation. All mipmap levels—such as $2\times$, $4\times$, and $8\times$ reductions—are generated in a single GPU compute dispatch, avoiding multi-level cumulative error (Landvater et al., 21 Apr 2025). The method uses floating-point 2D Laplacian-of-Gaussian kernels:

$$\text{LoG}(x,y) = -\frac{1}{\pi\,\sigma^4}\!\Bigl[1 - \tfrac{x^2 + y^2}{2\sigma^2}\Bigr] \exp\!\Bigl(-\tfrac{x^2 + y^2}{2\sigma^2}\Bigr)$$

The paper describes this as sharpening with no integer quantization blur. In practical terms, the compute stage is not limited to scale reduction; it also produces high-fidelity reduction-enhancements intended to improve the viewing of low-power cytology (Landvater et al., 21 Apr 2025). The reported rate for these reduction-enhancements is 100–160 $M$0 per slide tile.

The significance of this design lies in how it redefines lower-resolution layers. In many tile pyramids, reduced levels primarily serve navigation and are tolerated as visually degraded approximations. Iris instead computes reduction layers as diagnostically important rendering products. The paper explicitly associates this with increased visual quality for low-power cytology, where fine cellular patterns remain relevant even at reduced magnification (Landvater et al., 21 Apr 2025).

This suggests that Iris is not merely accelerating conventional pyramid traversal. A plausible implication is that it attempts to preserve perceptual and morphological detail during low-power inspection by making the reduced representation itself a compute-enhanced view.

5. VRAM management, explicit synchronization, and cache behavior

VRAM allocation in Iris Core is managed through an “Iris Wrapper Array,” in which each entry stores an allocation handle, a tile index hash, an atomic status flag from the set $M$1, and a reference count for multi-queue safety (Landvater et al., 21 Apr 2025). This wrapper allows VRAM allocations to be recycled while still tracking queue ownership and visibility state.

The paper places unusual emphasis on explicit cache ownership transfers. Each freshly buffered tile must have its L1/L2 cache control “ownership” explicitly transferred to the render queue before safe sampling; otherwise visible cache-coherency artifacts can occur (Landvater et al., 21 Apr 2025). Pipeline barriers and semaphores in Vulkan are therefore used not only for execution ordering, but also to ensure that no stale pixels ever appear.

Short-term caching operates in host RAM as a decompressed-tile cache, with eviction by least-recently used policy or cache-size limits (Landvater et al., 21 Apr 2025). Under heavy load, the reported behavior is counterintuitive: instead of slowing down, Iris often speeds up. The paper attributes this to cache mechanisms in which large bursts of transfer and compute push tile data into L1/L2 cache, after which render shaders immediately sample those same cached pixels, reducing fragment times from approximately 2 ms to near-0 ms (Landvater et al., 21 Apr 2025).

This cache-centric account is notable because it shifts the explanation of rendering throughput away from decoder throughput alone. The paper’s architecture treats memory locality, queue ownership, and cache reuse as first-class rendering concerns. A plausible implication is that the engine’s performance depends as much on coherent GPU residency and synchronization semantics as on raw storage or decompression bandwidth.

6. Quantitative performance and comparative position

All reported tests were conducted on 4 K+ displays, with an overall CPU/GPU memory footprint of approximately 2.5 GB (Landvater et al., 21 Apr 2025). Sustained frame rate was 120 FPS on all tested platforms, including a 2020 MacBook Pro M1 and an 11-inch M1 iPad Pro at 120 Hz, with median draw calls below 2 ms even under concurrent buffering.

The paper reports its principal rendering metrics as follows:

Metric	Iris Core / Iris Codec	Comparator
Sustained frame rate	120 FPS	120 FPS on all tested platforms
TeFOV, LR layer	10 ms (9–11 ms)	OpenSlide: 56 ms (45–87 ms)
TeFOV, HR layer	30 ms (20–33 ms)	OpenSlide: 124 ms (90–209 ms)
Prior published /FOV result	—	JavaScript/WebGL: 164–357 ms /FOV
TPT, HR, 256×256 px	0.10 ms/tile	OpenSlide: 0.60 ms/tile
TPT, LR, 256×256 px	0.16 ms/tile	OpenSlide: 1.32 ms/tile
Buffer-rate	1.36 GB/s median (1.01–1.69 GB/s)	decompressed image data into GPU+compute per second

TeFOV denotes time to buffer an entirely new field of view, and TPT denotes time per tile. For comparison with another viewer, the paper reports Aperio WebViewer at at least 2 ms/tile, or at most 500 tiles/s, and states that Iris is approximately 10–20 times faster in that context (Landvater et al., 21 Apr 2025). It also states that prior JavaScript/WebGL results of 164–357 ms per field of view are more than 10 times slower.

The paper further reports that Iris Core achieves a cumulative median buffering rate of 1.36 GB of decompressed image data per second and that this rate sustains full-frame buffering in under one monitor refresh, with high-resolution detail within 2–3 refreshes (Landvater et al., 21 Apr 2025). It also reports no slowing under high use loads, but rather an increase in performance due to cache mechanisms.

In its scaling discussion, the system is described as having near-unlimited parallelism: adding more CPU threads or GPUs directly translates to linear throughput gains, owing to stateless queues and Vulkan’s multi-queue families (Landvater et al., 21 Apr 2025). This is a claim about the design model rather than a full hardware-scaling study, but it indicates that the engine was conceived as a future-facing rendering substrate rather than a fixed-capacity viewer.

Taken together, these results position Iris as a rendering-engine architecture for digital pathology in which lock-free stateless CPU threads, hierarchical microtransactions, single-pass mipmap enhancement, and explicit L1/L2 cache synchronization are treated as interdependent components of real-time slide viewing. The paper’s own conclusion is that these mechanisms deliver performance well beyond existing digital pathology viewers, with reported order-of-magnitude gains in some contexts (Landvater et al., 21 Apr 2025).