Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0414cdeb4886bc95bbe545fe00bb1974dc9ed176
https://github.com/WebKit/WebKit/commit/0414cdeb4886bc95bbe545fe00bb1974dc9ed176
Author: Tim Horton <thor...@apple.com>
Date: 2025-07-16 (Wed, 16 Jul 2025)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm
M
Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFScrollingPresentationController.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/Plugins/PluginView.h
M Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp
Log Message:
-----------
[UnifiedPDF] WebContent process jetsams when iterating through find results
https://bugs.webkit.org/show_bug.cgi?id=295959
rdar://154292550
Reviewed by Simon Fraser, Abrar Rahman Protyasha, and Aditya Keerthi.
There were a few flaws in 296356@main that resulted in it being less of a win
than expected:
Firstly, UnifiedPDFPlugin::rectsForTextMatch (called in a tight
loop by WebFoundTextRangeController::rectsForTextMatchesInRect) still
creates PDFKit objects for all text matches in order to compute their rects,
and only filters out the visible ones at the end of the process.
Secondly, `visibleRectsForFindMatchRects` deals with "visibility" based
on the current set of visible pages. But this doesn't make sense when being
asked to paint matches for a given tile - a tile could easily cover a page
that isn't currently visible, and nothing will cause it to later repaint
when the page becomes visible.
Fix these issues by computing the set of pages covered by the painting
callback's
clip rect, instead of the "currently visible" ones, and filter the find matches
based on that page range *before* instantiating PDFKit objects (since that's
the expensive part).
This is a ~50x reduction in time spent under
WebFoundTextRangeController::rectsForTextMatchesInRect
on a simple benchmark (iterating the first 100 matches in a long document with
~700 marked matches).
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::rectsForTextMatchesInRect const):
(WebKit::UnifiedPDFPlugin::rectsForTextMatchesInRect):
(WebKit::UnifiedPDFPlugin::rectsForTextMatch): Deleted.
Restructure rectsForTextMatch such that it takes a set of matches and returns
all
the rects, instead of going one at a time. This is helpful because it means we
can
compute the page range for the clip rect only once.
(WebKit::UnifiedPDFPlugin::visibleRectsForFindMatchRects const):
Filter by the passed-in clip rect instead of the unobscured rect.
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
(WebKit::PDFLayoutRow::intersectsPageRange const):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::rectsForTextMatchesInRect):
(WebKit::PluginView::rectsForTextMatch): Deleted.
* Source/WebKit/WebProcess/Plugins/PluginView.h:
* Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp:
(WebKit::WebFoundTextRangeController::rectsForTextMatchesInRect):
Adapt the new `rectsForTextMatchesInRect` instead of `rectsForTextMatch`.
Canonical link: https://commits.webkit.org/297478@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
