To reproduce: 0. Have a display with a >1.0 scale factor 1. Go to data:text/html,%3Cdiv%20style=%22height:300px;width:300px;background-image:-webkit-repeating-linear-gradient(top%20left,%20red%2010%25,%20blue%2030%25);border:1px%20solid%22%3E Note that the diagonal lines in the gradient look chunky. They should look nice and smooth instead! In fact, they *do* look smooth if you remove the border.
<rdar://problem/10087050>
We need to audit all the places where we make ImageBuffers in the code to see if we need to use a scale factor. Or maybe we have ImageBuffer do this automatically.
The difference in rendering quality seen here when there's a border is due to how we render generated images as backgrounds. First, regardless of what type the background image is (in this case, a Gradient as GeneratorGeneratedImage) adding a border results in the background image being drawn as a pattern with more than one tile. If there were no border, we just draw the background image as one tile and hit the normal path. However, when there's a border, we pattern draw the background image so that it shows up behind the border as well with a padding-box-sized tile as is defined in the CSS spec (whether or not the border is opaque https://bugs.webkit.org/show_bug.cgi?id=78162) In this pattern draw case, we end up hitting GeneratorGeneratedImage's drawPattern instead of draw. Since 'draw' renders directly into the destination context - where as drawPattern renders a tile first in an ImageBuffer to then use - the generated image has the benefit of being at the resolution of the context. In the drawPattern case, the ImageBuffer that is created hasn't factored in the scale of the destination context. Thus, my patch teaches drawPattern about the scale to make tiles at a resolution that will match that of the destination context.
Created attachment 126165 [details] Patch
Committed r107157: <http://trac.webkit.org/changeset/107157>