With recent changes to enable multiple picture caching slices, some pages (in particular, those with a large fixed background image / gradient) will lose subpixel AA with WR enabled. The tradeoff is that we will see significantly better rasterization performance (and battery usage).
I believe this is the same tradeoff that Chrome makes (dropping subpixel AA in these page layouts). Our goal is to ensure we have subpixel AA working in any case where Chrome also manages to do subpixel AA. So, if we come across pages where Chrome gets subpixel AA, but WR doesn't that would be a bug we'd aim to fix.
Drawing with subpixel AA on these pages requires either (a) a memory and performance intensive technique where the scrolling content is rasterized twice and mixed during compositing or (b) rasterizing the entire page every time there is a scroll event, due to the fixed background image moving relative to the scrolled content. Notably, (a) is not compatible with OS compositor integration.
By dropping subpixel AA for these page layouts, we can rasterize the content in separate slices and cache these between frames, only compositing them as they scroll at different rates. Further, we can draw these slices directly into OS compositor surfaces (such as DirectComposition and CoreAnimation) for further performance savings and battery wins.
One option we might consider, going forward, is to add a user preference that allows a switch between:
(1) High performance and better battery usage (dropping subpixel AA in these specific cases) or
(2) Higher text rendering quality (enable subpixel AA for these cases, rasterize every frame)
This would allow users that want subpixel AA to enable it, with knowledge of the impact on battery life and performance.