Created attachment 167856 [details] Example Using Safari Mac Nightly r130772 with Safari version Version 6.0.1 (8536.26.14) on Mac Adjusting the CSS left property of an element with a non-zero border-radius may leave a noticeable repaint trail. You can observe this issue by using the attached example, example.html, and performing the following steps: 1. Open example.html. 2. Click the blue square 10 times. Notice that the left edge of the blue square is painted multiple times from the left edge of the window to its current position. Once you become familiar with the issue you may find that you can reproduce it by clicking the blue square less than 10 times. For completeness, I was able to reproduce this issue with Mac Nightly r130772 and Safari version 6.0.1 (8536.26.14) on Mac OS 10.8.2.
Created attachment 167858 [details] Screenshot of repaint trail A screenshot of the repaint trail produced using the instructions in the bug description.
(In reply to comment #0) > Using Safari Mac Nightly r130772 with Safari version Version 6.0.1 (8536.26.14) on Mac Adjusting the CSS left property of an element with a non-zero border-radius may leave a noticeable repaint trail. I meant to write: Adjusting the CSS left property of an element with a non-zero border-radius may leave a noticeable repaint trail.
You can also observe this repaint trail in Paul Irish's requestAnimationFrame() example, <http://jsfiddle.net/paul/rjbGw/3/> (used to derive the attached example.html). This JSFiddle example is referenced from <http://paulirish.com/2011/requestanimationframe-for-smart-animating/>.
Does this reproduce if you disable full-screen accelerated drawing (using Safari’s Debug menu) and open a new window?
(In reply to comment #4) > Does this reproduce if you disable full-screen accelerated drawing (using Safari’s Debug menu) and open a new window? No, this issue doesn't reproduce when I disable full page accelerated drawing.
Thanks for confirming that. This is an issue in Quartz which is being tracked by Apple, and not something to be addressed in WebKit, so closing as Invalid per our convention.
A little late, but for anyone who still has issues with this behaviour I've come up with a couple of workarounds: 1. Add a very faint box shadow (e.g. "box-shadow: 0 0 1px rgba(0, 0, 0, 0.05)") to the element, increasing the dimensions of the damage rect to include the stray antialiased pixels. This is the simplest and least problematic method, IMO. 2. Use the old translateZ hack ("-webkit-transform: translateZ(0)") so that the element is rendered as a separate compositing layer. Less recommended, has implications for performance.