Thanks for filing the issue!

Tried checking the issue on reported chrome version 69.0.3497.100 using Ubuntu 14.04 with the below mentioned steps.
1. Launched Chrome
2. Navigated to https://codepen.io/anon/pen/pxgZmG
3. Hovered over the divs and observed the transition.

@Reporter: We observed the transition was proper when hovered upon, attaching the screencast of the same for reference. Could you please have a look at the screen cast and let us know if we have missed anything in the process. Any further inputs from your end may be helpful.

Deleted: 891678.ogv 1013 KB

	891678.ogv 1013 KB View Download

It's really hard to see in the attached video, because of high compression. And it's really a matter of pixel-size offsets.

I've created a different setup that puts the transitions side by side to better demonstrate this issue:

1. Launch Chrome
2. Navigate to https://codepen.io/anon/pen/GYZzJY
3. Hover over the bordered area to trigger transition

The transition is not the same for both halves and I see it clearly at the point when they touch each other. The left one, not rounded, is not as smooth and even seems to overshoot for a frame when retracting to unhovered position.  Attaching a better quality capture as well.

Contents of the Codepen https://codepen.io/anon/pen/GYZzJY in case it gets lost: 

HTML:

Hover within border
<div class="parent">
  <div class="clip">
    <div class="child"></div>
  </div>
  <div class="clip">
    <div class="child round"></div>
  </div>
</div>

CSS:

body {
  padding: 30px;
}

.parent {
  display: flex;
  padding: 30px;
  border: 1px solid;
}

.clip {
  width: 100px;
  height: 100px;
  overflow: hidden;
}

.child {
  width: 200px;
  height: 50px;
  margin-left: -50px;
  box-shadow: 0px 8px 8px;
  transition: box-shadow 1s;
}

.round {
  border-radius: 1px;
}

.parent:hover .child {
  box-shadow: 0px 16px 16px;
}

Deleted: capture.webm 6.4 MB

	capture.webm 6.4 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Any update on this? I'm wondering if I should create an internal Google issue if stays restricted, because I want to reference this in workaround documentation.

Able to reproduce the issue on Mac 10.13.6, Debian rodete & Windows10 using chrome reported version-69.0.3497.100 & latest Canary-72.0.3608.0 as per steps mentioned in C#0&4.

Observed box shadow transition is not smooth from M60 builds to latest Canary. As it is non regression issue, marking it as Untriaged to get it addressed from dev team.

Thanks!!

This bug was automatically marked Google internal as it was filed by an @google, but contains no Google-internal info that I can see. Marking allpublic.

It interests me that the OP thinks that the box with rounded-corners animates smoother, as I visually see the opposite (based on zooming both https://output.jsbin.com/sejeri/quiet and https://output.jsbin.com/tumubab/quiet and staring at my screen for a while). To me the non-border-radius element animates smoothly whilst there is very slight visual distortion in the border-radius one.

There doesn't appear to be a compositing interplay here; there are no layers in low or high DPI other than the main document. I'm also not sure I would consider this an animations bug; we are probably setting identical style on both elements at a given frame (will double check). Likely it is a case of them being painted slightly differently for whatever reason.

Oh, I just ran https://output.jsbin.com/sejeri/quiet on my Linux desktop and the LHS non-border-radius looks terrible! (So my apologies to the OP). On my HP Chromebook they look very close (which is comment #10). Still no layers.

Adding Paint team, since this is main-thread bound.

Checked: on the animation side we are setting identical pairings of box shadow on the style, so this seems definitely Paint-ish.

[1:1:1213/101544.747272:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8, 8
[1:1:1213/101544.750745:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8, 8
[1:1:1213/101544.763376:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8.04527, 8.04527
[1:1:1213/101544.763681:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8.04527, 8.04527
[1:1:1213/101544.780305:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8.15098, 8.15098
[1:1:1213/101544.780667:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8.15098, 8.15098
[1:1:1213/101544.796311:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8.26171, 8.26171
[1:1:1213/101544.796717:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 8.26171, 8.26171
...
[1:1:1213/101545.714552:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 15.9954, 15.9954
[1:1:1213/101545.714979:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 15.9954, 15.9954
[1:1:1213/101545.731745:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 15.9988, 15.9988
[1:1:1213/101545.732157:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 15.9988, 15.9988
[1:1:1213/101545.748149:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 16, 16
[1:1:1213/101545.748559:INFO:css_shadow_list_interpolation_type.cc(183)] Setting box shadow: 0, 16, 16

On Windows I see the following:
With GPU raster Enabled, both look bad but the rounded corner is worse.
With GPU disabled, the rounded corner looks good but the square corner is bad.
Disabling the overflow clip does not make a difference, so it's not related to the clip.

I have to think this is a GPU raster issue because we do not issue different paint commands depending on the GPU setting.

This looks like a rounding problem in skia raster? It's easy to repro in the codepen on linux.