Dragging to view spikes memory, crashing some computers

[wsfc-001]

Viewing PDFs on Windows causes a sharp memory rise. Dragging to view spikes memory, crashing some computers. Any optimization methods?

[espresso3389]

PdfViewerParams has the following variables to control PDF caching:

  /// If true, the viewer limits the rendering cache to reduce memory consumption.
  ///
  /// For PDFium, it internally enables `FPDF_RENDER_LIMITEDIMAGECACHE` flag on rendering
  /// to reduce the memory consumption by image caching.
  final bool limitRenderingCache;

...

  /// Restrict the total amount of image bytes to be cached on memory. The default is 100 MB.
  ///
  /// The internal cache mechanism tries to limit the actual memory usage under the value but it is not guaranteed.
  final int maxImageBytesCachedOnMemory;

  /// The horizontal cache extent specified in ratio to the viewport width. The default is 1.0.
  final double horizontalCacheExtent;

  /// The vertical cache extent specified in ratio to the viewport height. The default is 1.0.
  final double verticalCacheExtent;

[wsfc-001]

这是来自QQ邮箱的假期自动回复邮件。您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

[espresso3389]

This may be related to #604.

I found and fixed a cancellation gap in PdfViewer rendering in 14565658.

The issue was in the shared PdfViewer rendering/cache path, not in an iOS/Android-specific path:

• When pages moved outside the cache target area, PdfViewer called cancelPendingRenderings(pageNumber).
• However, that only canceled render cancellation tokens.
• It did not cancel pending preview image timers or pending partial image rendering requests/timers.
• During fast scrolling or dragging, delayed render requests for pages that were no longer visible could still wake up and render images later, increasing memory usage.

The fix in 14565658 now cancels those offscreen preview/partial rendering requests and prevents stale completed requests from updating the image cache.

Because this code path is platform-independent and Windows also uses the PDFium backend, this fix may improve the Windows memory spike reported here as well.

Could you try the latest master after 14565658 and check whether the memory spike is improved?

[wsfc-001]

这是来自QQ邮箱的假期自动回复邮件。您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

[wsfc-001]

Thank you, I'll take a look after upgrading