When going to paint, PDFDocumentImage transforms the context by scaling into "page" space. It currently does so on a per-axis basis, but this means that sometimes small floating-point rounding issues can cause the scales to be slightly different. This causes us to do a non-uniform scale which both imperceptibly squishes the PDF and throws CoreGraphics onto a slow painting path.
<rdar://problem/15770980>
I guess we have to decide whether PDF-in-<img> should behave like an image (and stretch if width and height are both specified) or like an SVG (and fit inside the box).
Created attachment 220617 [details] patch If we decide it should behave like SVG and fit inside the box, this patch will do.
Attachment 220617 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCore/platform/graphics/cg/PDFDocumentImage.cpp', '--commit-queue']" exit_code: 1 ERROR: Source/WebCore/platform/graphics/cg/PDFDocumentImage.cpp:139: Use std::min() or std::min<type>() instead of the MIN() macro. [runtime/max_min_macros] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 220619 [details] style
Comment on attachment 220619 [details] style Nice find! This is really an "aspect-ratio fit" right? Do we have other code for that?
Created attachment 220754 [details] new approach
http://trac.webkit.org/changeset/161568
Layout test in http://trac.webkit.org/changeset/161581