If you apply a scale factor to a page with compositing layers via the _scaleWebView SPI, the composited layers will scale, and the other layers will not. Also, the painting is clipped at the boundaries of the size of the un-scaled WebView. This does not happen on pages without compositing layers.
Created attachment 76714 [details]
Simon was worried that docWidth and docHeight might be incorrect at times -- especially if they could ever be negative. I feel confident that they are correct here because of Hyatt's description in the ChangeLog for r73885: "RenderView now uses docLeft/Top/Height/Width functions, which are just overflow queries that account for writing modes. These methods are now the preferred way to query for the physical dimensions of a document." Also, all of the layout tests pass, and I did some testing on LTR and RTL web sites with compositing layers.
(In reply to comment #1)
> Created an attachment (id=76714) [details]
> Simon was worried that docWidth and docHeight might be incorrect at times -- especially if they could ever be negative.
To clarify, it's top/left I'm worried about. I think the graphics layer origin might have to be adjusted in some situations (like RTL, or vertical text).
And thanks for clarifying, Simon. Simon and I looked at this more closely, and he was correct that there are still some problems on RTL pages with compositing layers that start with a horizontal scrollbar and content anchored to the right side of the page. I have a test case for that and will file a follow-up bug.
In the meantime, I committed this patch with revision 74168.
Filed https://bugs.webkit.org/show_bug.cgi?id=51158 as a follow-up for the RTL issue mentioned above.