Rendering Diagnostics and Operation Telemetry

HotPDF distinguishes rendered-page cache entries by every caller-visible state that can change page pixels and exposes bounded diagnostics when page content cannot be rendered completely

State-aware cache variants

THotPDF.RenderLoadedPageToBitmapCached keys memory entries by page, DPI, effective optional-content visibility, THotPDF.RenderColourIntent, and THotPDF.RenderFallbackPolicy

The persistent cache uses the same state digest, while diagnostic-producing fallback modes remain memory-only so a disk hit cannot lose skipped-object reports

Changing an optional-content group selects another variant instead of deleting the previous bitmap, so switching a layer or colour intent back can reuse earlier work

Colour intent

PDF.RenderColourIntent := rciRelativeColorimetric;
Bitmap := PDF.RenderLoadedPageToBitmapCached(0, 144);

rciDocument honours each content-stream ri operator and remains the default

The four explicit values override content-stream intent selection and are applied to subsequent ICCBased fill and stroke conversions

Fallback policy

PDF.RenderFallbackPolicy := rfpReport;
PDF.RenderFallbackDiagnosticLimit := 256;
Bitmap := PDF.RenderLoadedPageToBitmap(0, 144);
Diagnostics := PDF.GetLastRenderFallbackDiagnostics;

THotPDF.GetLastRenderFallbackDiagnostics returns the retained set, while THotPDF.ClearLastRenderFallbackDiagnostics clears it; cached report-mode entries retain their diagnostic set, so a memory cache hit returns the same rendering completeness information as the original render

Unified operation telemetry

if PDF.GetLastOperationTelemetry(Info) then
begin
  WriteLn(Info.OperationName);
  WriteLn(Info.ElapsedMilliseconds);
  WriteLn(Info.CPUTimeMicroseconds);
  WriteLn(Info.PeakProcessMemoryBytes);
  WriteLn(Info.MemorySchedulerWaitMilliseconds);
  WriteLn(Info.DecodeExpansionPermille);
end;

THotPDF.GetLastOperationTelemetry returns a THPDFOperationTelemetry record containing wall time, current-thread CPU time, memory, allocation, process I/O, filter decode, cache, object-count, success, and cancellation metrics

Document loading, synchronous and cached page rendering, progressive render slices, selective stream optimisation, and parallel image optimisation publish the same record shape

PeakMemoryBytes is a portable document-operation estimate rather than the operating-system process working set, so it remains stable across hosts and includes loaded source bytes, rendered bitmap entries, decoded-image cache weight, and peak filter-chain storage

PeakProcessMemoryBytes is the largest sampled process working set, while AllocationCount is the largest sampled increase in concurrently live Delphi memory-manager blocks relative to operation start rather than a lifetime allocation total

CPUTimeMicroseconds measures the calling thread, while ReadIOBytes, WriteIOBytes, and OtherIOBytes are process-wide counter deltas and can therefore include concurrent work in the same process

DecodeInputBytes is compressed input, DecodeOutputBytes is final filter-chain output, and DecodedBytes is aggregate work across every filter stage; DecodeExpansionPermille divides final output by input, with 1000 representing 1x

ScheduledMemoryBytes is the operation admission estimate, MemorySchedulerWaitMilliseconds records queue time, and MemorySchedulerDelayed distinguishes queued admission from the allocation-free fast path

Memory and allocation peaks are sampled at operation boundaries, filter-chain completion, progressive slices, and cancellation checkpoints, so they are low-overhead operational signals rather than instruction-level profiler traces

API-uri asociate