RenderPageProgressive method

Cancellable variant of RenderPage that drives PDFium's progressive rendering loop and polls an IPdfCancellationToken between iterations so long high-DPI renders can abort mid-page instead of blocking until completion

Color = clNone or Color = clDefault selects a transparent background and an alpha-capable PDFium bitmap. Uncovered pixels retain zero alpha independently of the native page background-transparency query, including partially rendered results returned after cancellation; clWhite remains the default opaque background

RenderPageProgressive renders the current page into the supplied Bitmap using PDFium's FPDF_RenderPageBitmap_Start + FPDF_RenderPage_Continue loop. Between iterations, PDFium's IFSDK_PAUSE callback polls AToken.IsCancelled — when the application has cancelled, the loop unwinds cleanly and the bitmap holds the partial work done so far

PDFium renders directly into a compatible destination bitmap buffer. Native LCL buffers must also have the expected byte order, channel shifts, line order and stride; other layouts are converted using their actual raw-image description

The return value identifies how the render finished:

• prsDone — the bitmap is fully rendered. Equivalent to a successful synchronous RenderPage
• prsCancelled — the caller cancelled mid-loop. The bitmap holds the partial result up to the iteration where cancellation was detected; treat it as best-effort preview content
• prsFailed — PDFium reported FPDF_RENDER_FAILED. The bitmap state is undefined

Pass AToken = nil to render to completion without ever pausing. In that case the function still pumps FPDF_RenderPage_Continue until DONE but never returns prsCancelled. This is useful when the caller wants the progressive loop's intermediate redraw points (a custom OnPaint that mirrors the in-progress bitmap) but does not need cancellation

• The bitmap must be allocated by the caller. Windows bitmaps use pf32bit; native LCL bitmaps retain their platform description and use direct rendering only when the actual buffer layout is compatible
• Width / Height are in pixels (the destination bitmap's dimensions). The page is scaled to fit those dimensions before the progressive loop kicks off
• RenderPageProgressive itself is synchronous from the caller's point of view — it returns when the render finishes or cancels. To free the main thread, drive RenderPageProgressive from a worker thread. TPdf serializes render calls per instance; callers still must avoid mutating or unloading the document while a render is in flight
• An EPdfError is raised when Bitmap is nil — the contract requires a caller-allocated bitmap because the zero-copy path needs a known DIB layout

RenderPage, RenderTile