Pluggable Page Render Backends

HotPDF can route loaded-page bitmap rendering through an application-defined backend while retaining the existing renderer as the zero-configuration default and optional fallback

Built-in native backend

PDF.UseNativeGDIRenderBackend;
Bitmap := PDF.RenderLoadedPageToBitmap(0, 144);

THPDFNativeGDIRenderBackend exposes the established Windows native GDI renderer through the same public backend contract used by external implementations

Its capabilities declare prbcNative, prbcDeterministic, prbcTransparency, prbcColourManagement, and prbcThreadSafe without claiming prbcDeviceAcceleration

SIMD scanline backend

var
  Backend: IHPDFPageRenderBackend;
begin
  Backend := THPDFSIMDScanlineRenderBackend.Create;
  PDF.PageRenderBackend := Backend;
  Bitmap := PDF.RenderLoadedPageToBitmap(0, 144);
end;

THPDFSIMDScanlineRenderBackend preflights the complete compiled display list, then writes supported DeviceRGB or DeviceGray rectangle fills directly into the final 32-bit bitmap surface through 64-byte batches and 16-byte vector tails

Compound rectangle paths follow the nonzero or even-odd fill rule as one paint operation, preserving holes, transformed subpath direction, and previously painted content; rasterization checks cancellation in bounded batches and discards partial surfaces

The backend accepts graphics-state save and restore, orthogonal scale, translation and right-angle rotation matrices, fill color changes, rectangles, fill operators, and path reset; text, arbitrary paths, strokes, images, transparency, clipping, patterns, shadings, unsupported color spaces, and non-orthogonal transforms decline before bitmap allocation

Its capabilities declare prbcSIMD, prbcThreadSafe, and prbcDeterministic without claiming device acceleration, transparency, or color management

THPDFSIMDRenderBackendStatistics reports direct surfaces, rendered rectangles, vector blocks, scalar tail pixels, and the exact rejected operator when fallback is required

Custom backend contract

Implement IHPDFPageRenderBackend and assign it to THotPDF.PageRenderBackend

THPDFPageRenderBackendRequest supplies the requested page index and DPI, the compiled THPDFPageDisplayList, and a THPDFRenderDocAccess resolver for streams, images, fonts, optional content, color management, and cancellation

A backend can inspect each compiled operator through THPDFPageDisplayList.GetToken without reparsing page content

Return True with a newly allocated TBitmap to transfer bitmap ownership to HotPDF; return False with no bitmap to decline the request

Concurrency and fallback

Backends declaring prbcThreadSafe can run concurrently through both parallel page-render pipelines

Backends without that capability are serialized through a dedicated call lock while display-list compilation remains concurrent

rbfpSoftwareFallback retries an unavailable, declined, or failed backend request with the existing renderer, while rbfpFail raises EHPDFRenderBackend

A backend can optionally implement IHPDFPageRenderBackendFailureInfo or return a per-request diagnostic reason so concurrent declines retain the reason for the exact render attempt

Changing the backend invalidates in-memory and persistent rendered-page cache entries so images from different renderers are never mixed

Diagnostics and visual gate

THPDFRenderBackendStatistics reports attempts, successes, failures, software fallbacks, serialized calls, elapsed time, backend name, and the last failure reason