Chrome Version       : 55.0.2883.95
OS Version: OS X 10.12.3
URLs (if applicable) : http://codepen.io/TrevorBurnham/pen/pRWOvL
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 10.0.3: OK
  Firefox 51.0.1: OK

What steps will reproduce the problem?
1. Go to http://codepen.io/TrevorBurnham/pen/pRWOvL
2. Use the button to toggle `display: none` on the absolute-positioned element inside of the container with `filter: blur(3px)`.
3. Use Timeline tool to compare the page's performance performance between the two states.

What is the expected result?

Whether the absolute-positioned element in the blurred container has `display: none` or not should have no impact on page performance, since the element is not changing in any way, and furthermore has no content.

What happens instead of that?

In the state where the absolute-positioned element doesn't have `display: none`, the page heavily utilizes the GPU, apparently continuously repainting the blurred container. At a large enough window size, this causes the frame rate to drop. This is surprising because the page's sole animated element is fixed-positioned and not a descendant of the blurred container. The blurred container should only need to be painted once.

Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

I don't see any performance discrepancy between the two states of that page in Safari or Firefox.

The `overflow: hidden` value in the wrapper around the blurred container is an important piece of the puzzle. Remove that rule and the discrepancy goes away. The Timeline indicates that the compositing heuristic that causes the absolute positioned ancestor to be promoted to its own layer (somehow causing its container to be repainted?) is "Has clipping ancestor."

Side note: In the real application where I ran into this issue, the absolute-positioned elements in the blurred container were intended only for screen readers, using the common technique:

    .sr-only { position: absolute; clip: rect(0, 0, 0, 0); }

So adding a special rule to treat elements with `clip: rect(0, 0, 0, 0)` the same as elements with `display: none` for compositing purposes would mitigate the issue.
 

Deleted: timeline-without-abs-positioned-element.png 310 KB

	timeline-without-abs-positioned-element.png 310 KB View Download

Deleted: timeline-with-abs-positioned-element.png 310 KB

	timeline-with-abs-positioned-element.png 310 KB View Download