
Painting in PdfViewWebPlugin uses a current image snapshot to draw onto the canvas. This gets updated after PaintManager finishes doing a flush of paint requests. After a stroke has been added to a PDF page, PdfInkModule makes an invalidate call which kicks off the request to redraw the area where the stroke occurred. However, there can be a call for PdfViewWebPlugin to paint before the snapshot has been updated. This presents a period where the snapshot does not include the newly drawn Ink stroke, and there are no longer any in-progress Ink inputs held by PdfInkModule. This can result in a flash, where the paint uses only the now-stale snapshot. Avoid the flash effect where a newly drawn Ink stroke temporarily disappears by retaining the snapshot rendering of the in-progress Ink stroke. Reuse this in PdfViewWebPlugin::Paint() until the current image snapshot gets updated. Fixed: 380057101 Change-Id: Icda9260a6d022f3458f0ae1e28dfa5d492daa8c8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6363095 Reviewed-by: Andy Phan <andyphan@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Alan Screen <awscreen@chromium.org> Cr-Commit-Position: refs/heads/main@{#1433897}
//pdf
contains the PDF plugin, its Blink-based replacement, as well as PDF
utility functions that leverage PDFium. It can use low-level components that
live below the content layer, as well as other foundational code like
//printing
. It should not use //content
or anything in //components
that
lives above the content layer. Code that lives above the content layer should
live in //components/pdf
, or in the embedder. All the code here should run in
sandboxed child processes.
TODO(crbug.com/40186598): Remove existing //content
dependencies.