Here is a more dramatic example. Mousing between the two icons on the left (which have a CSS transition enabled for opacity) causes dramatic visible jittering and glitches as the compositor does... whatever it is it's doing.

Most of the elements glitching out do not have transforms applied to them.

Deleted: sidebar combat.mp4 2.4 MB

	sidebar combat.mp4 2.4 MB View Download

Style looks like it's doing the right thing - this appears to be a paint/raster problem. Assigning to the paint team to triage.

Incidentally, in that most recent example I was able to mitigate the glitching by splitting each set of elements into its own containing box. I had to also make sure they were all laid out with position:absolute (not relative) and set an explicit line-height on all the text. That resulted in most of the boxes and text elements being laid out at integral coordinates without blurring or jittering.

The icons near the bottom with the transitions still exhibit compositor issues, though, as do the existing parts of the game you can see bounce between filtered/unfiltered in the clip.

So it seems like a bunch of things can cause a group of elements to get put into some sort of compositor group here, and then everything in that group suffers from quality issues during transitions/animations.

This is a known issue with subpixel layer positioning. You're seeing it because opacity is a trigger for compositing. You can probably work around it by always setting opacity less than 1.

I think this is basically a duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=521364

Why is it blurry if all the offsets are integral? According to the computed layout in the dev tools, and my stylesheets, everything is at integer positions. Is it because I'm on a high-DPI panel and that's causing Chrome to do the wrong thing here?

For a specific example:
The tiny icon labelled with a '52' is an absolutely-positioned box contained within another absolutely-positioned box. Neither of them have any transforms or opacity values applied. The '52' icon has an :after element containing the number and an rgba background color to dim the icon.

If I remove the rgba background color and apply an opacity value to the icon, the icon and everything else in the containing box (see the meters above it) all become blurry. This is despite the fact that all the offsets are integer values, as are the sizes of the boxes and the font sizes and line heights.

I can't imagine why subpixel coordinates would come into play here. All the coordinates are integers. Furthermore, the positioning of the background images (if you look closely at the icon) gets messed up on the Y axis when compositing is turned on, which seems like it absolutely is a bug.

Deleted: Screenshot 2016-07-13 16.42.32.png 93.4 KB

	Screenshot 2016-07-13 16.42.32.png 93.4 KB View Download

I think it is a dupe of 521364. Layout is snapped to CSS pixel, but CSS pixel may not always align with device pixels. A few win10 tablets shipped with default 150% device scale. The blurriness is due to layers that are aligned to even pixels getting squashed into a layer that's aligned to odd pixel.

To kg@: Your intuition is very accurate: "it seems like a bunch of things can cause a group of elements to get put into some sort of compositor group here". It is an optimization called layer squashing in Chrome.

While the blurry text issue remains, the 'bouncing between filtered and unfiltered for composited layers' issue (as seen on the health bar in Comment 1) does seem to be fixed in Chrome 53.