Bug 98825

Summary: Adjusting CSS left property on element with border-radius leaves repaint trail
Product: WebKit Reporter: Daniel Bates <dbates>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: eric, hyatt, jamesr, j.b.gray, mitz, mjs, simon.fraser
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Macintosh   
OS: OS X 10.8   
Attachments:
Description Flags
Example
none
Screenshot of repaint trail none

Description Daniel Bates 2012-10-09 15:07:55 PDT
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.
Comment 1 Daniel Bates 2012-10-09 15:15:33 PDT
Created attachment 167858 [details]
Screenshot of repaint trail

A screenshot of the repaint trail produced using the instructions in the bug description.
Comment 2 Daniel Bates 2012-10-09 15:16:33 PDT
(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.
Comment 3 Daniel Bates 2012-10-09 15:52:48 PDT
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/>.
Comment 4 mitz 2012-10-10 13:07:48 PDT
Does this reproduce if you disable full-screen accelerated drawing (using Safari’s Debug menu) and open a new window?
Comment 5 Daniel Bates 2012-10-11 09:07:25 PDT
(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.
Comment 6 mitz 2012-10-11 09:12:36 PDT
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.
Comment 7 Jordan Gray 2014-04-29 06:18:40 PDT
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.