This is most likely a duplicate of issue 740459. Rewording description a bit.

I don't think it is 740459. I think this might be a straight-up bug. We should
be re-rastering at end of scale change.

What element is animating the scale change when clicking outside of the dialog?

The code is at [1]. It is actually using the Web Animations API, no a CSS transform.

[1] https://cs.chromium.org/chromium/src/ui/webui/resources/cr_elements/cr_dialog/cr_dialog.js?dr&l=213

Great thanks. We're debugging now.

I think the trigger to end animations and update draw properties is not
getting called. LTHI::ElementIsAnimatingChanged is I think never called
at the end of the web animation of transform.

Animations team, could you look into it?

Fascinating; this does not repro on Linux or Windows, but does on Mac. I'm not aware of any OS-specific behavior we have around the animations code*, but will take a look.

* Disclaimer: I haven't checked for possible high/low DPI differences in this bug masquerading as OS-specific behavior.

It's a little hard to tell because it's quite a spammy log, but I do see the following block of calls (split for readability) to PropertyTrees::ElementIsAnimatingChanged when I initiate this animation;

[96843:775:0326/111511.929000:INFO:layer_tree_host.cc(1544)] Calling from LTH
[96843:775:0326/111511.929070:INFO:property_tree.cc(1786)] PropertyTrees::ElementIsAnimatingChanged, !transform_node

[96843:40195:0326/111511.932432:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x7ff25e04d000
[96843:40195:0326/111511.932477:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[96843:40195:0326/111511.932507:INFO:property_tree.cc(1782)] updated_transform = true
[96843:40195:0326/111511.949038:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x7ff25b002800
[96843:40195:0326/111511.949088:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[96843:40195:0326/111511.949120:INFO:property_tree.cc(1782)] updated_transform = true

[96843:775:0326/111512.100144:INFO:layer_tree_host.cc(1544)] Calling from LTH
[96843:775:0326/111512.100223:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[96843:775:0326/111512.100269:INFO:property_tree.cc(1782)] updated_transform = true
[96843:775:0326/111512.100297:INFO:layer_tree_host.cc(1544)] Calling from LTH
[96843:775:0326/111512.100331:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[96843:775:0326/111512.100350:INFO:property_tree.cc(1782)] updated_transform = true

[96843:40195:0326/111512.105958:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x7ff25b002800
[96843:40195:0326/111512.105999:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[96843:40195:0326/111512.106024:INFO:property_tree.cc(1782)] updated_transform = true
[96843:40195:0326/111512.106058:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x7ff25e04d000
[96843:40195:0326/111512.106077:INFO:property_tree.cc(1786)] PropertyTrees::ElementIsAnimatingChanged, !transform_node

So on the LTHI, there are three calls where the transform_node exists and updated_transform is set to true, then one final one where the transform_node doesn't exist. The |tree| always exists for each call from LTHI.

I'm going to compare this to a equivalent log on Linux and see what I get.

Equivalent log on my Linux workstation, where the text doesn't stay blurry:

[1:1:0326/112122.073669:INFO:layer_tree_host.cc(1544)] Calling from LTH
[1:1:0326/112122.073902:INFO:property_tree.cc(1786)] PropertyTrees::ElementIsAnimatingChanged, !transform_node

[1:10:0326/112122.081302:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x2df35760ba00
[1:10:0326/112122.081502:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[1:10:0326/112122.081626:INFO:property_tree.cc(1782)] updated_transform = true
[1:10:0326/112122.093755:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x2df35760b400
[1:10:0326/112122.093953:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[1:10:0326/112122.094066:INFO:property_tree.cc(1782)] updated_transform = true

[1:1:0326/112122.260863:INFO:layer_tree_host.cc(1544)] Calling from LTH
[1:1:0326/112122.261136:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[1:1:0326/112122.261255:INFO:property_tree.cc(1782)] updated_transform = true
[1:1:0326/112122.261351:INFO:layer_tree_host.cc(1544)] Calling from LTH
[1:1:0326/112122.261423:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[1:1:0326/112122.261494:INFO:property_tree.cc(1782)] updated_transform = true

[1:10:0326/112122.270883:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x2df35760b400
[1:10:0326/112122.271090:INFO:property_tree.cc(1767)] PropertyTrees::ElementIsAnimatingChanged, transform_node exists
[1:10:0326/112122.271176:INFO:property_tree.cc(1782)] updated_transform = true
[1:10:0326/112122.271232:INFO:layer_tree_host_impl.cc(4937)] LTHI, will call if tree exists, tree: 0x2df35760ba00
[1:10:0326/112122.271279:INFO:property_tree.cc(1786)] PropertyTrees::ElementIsAnimatingChanged, !transform_node


Looks identical to me, so I'm thinking this is not an animations bug.

I'm just going to try and verify that we do end up with a 1.0 scale transform, but beyond that I don't think it's going to turn out to be animations.

The last call to NotifyClientTransformOperationsAnimated seems close to the identity matrix, though there's a slight difference between Mac and Linux (on my testing devices, could just be from monitor scale/etc):

Mac:

[98133:41475:0326/114525.877934:INFO:element_animations.cc(284)] Active, [ +1.0006 +0.0000 +0.0000 +0.0000  
  +0.0000 +1.0006 +0.0000 +0.0000  
  +0.0000 +0.0000 +1.0000 +0.0000  
  +0.0000 +0.0000 +0.0000 +1.0000 ]

Linux:

[1133:41375:0326/113712.327134:INFO:element_animations.cc(284)] Active, [ +1.0002 +0.0000 +0.0000 +0.0000  
  +0.0000 +1.0002 +0.0000 +0.0000  
  +0.0000 +0.0000 +1.0000 +0.0000  
  +0.0000 +0.0000 +0.0000 +1.0000 ]



Anyway, I don't think there's much left here animations wise, so passing back to Chris. Feel free to re-tag us if I turn out to be wrong!

Anything other than the identity matrix is incorrect. If there is
 no notification at the actual end of the animation then we may not get
a rendering at the correct scale.

Ack. I've been experimenting and I would estimate that most of the time we don't ever call KeyframedTransformAnimationCurve::GetValue with a time == animation end time (maybe 1 in ever 5 runs of the animation), so if doing so is required for correct output on the cc layer tree then that is rarely going to work... :(. Looking into that now.

Incidentally, if I click repeatedly outside the dialog box (e.g. repeatedly triggering the animation whilst it is still going on), eventually I can DCHECK the browser:

[1:10:0326/152256.161658:FATAL:picture_layer_impl.cc(1412)] Check failed: !draw_properties().screen_space_transform_is_animating. 

The callstack looks to be from the updating of drawing properties after LTHI::CommitComplete. This DCHECK may or may not be related (probably not, given that I'm interrupting the animation before it finishes most of the time?)

(Drat, meant to add both animation labels back and instead swapped them.)

#17 is misleading, for two reasons:

i. cc/ animations are never expected to finish with exactly the last keyframe. Instead in this case blink receives the animation-finished event and updates the layer via Layer::SetTransform with the final keyframe. I have confirmed that this happens (setting the identity matrix) for both Mac and Linux.

ii. Additional logging shows that sometimes we do happen to hit exactly the cc-last-keyframe case (thus calling NotifyClientTransformOperationsAnimated with the identity matrix) on Mac, and the result is *still* blurry until you force a redraw (e.g. by highlight text or alt-tabbing).

On advice of flackr@ I'm going to try to track down where we set the raster scale and debug backwards from there.

Thanks for looking into it again! Really appreciate it. I think nailing this issue
in particular is important to ensure quality animations, hence my extra attention.

There have been consistently many reports from those trying to use compositing and
animations on the web about bluriness (from many sources; my point is that blurriness
is an issue to which people are highly sensitive.

Also, vmpstr is available if you have any questions, he is actually the one who, along
with pdr, did the initial deep dive on this bug.

Investigations so far show that (as far as I can tell) all PictureLayerImpls which end up with a raster scale != 1.0 during the animation do go back to 1.0 after it is finished, and as far as I can tell a draw does then happen (I put a log in ProxyImpl::DrawInternal and confirmed it fires and 'host_impl_->DrawLayers(&frame)' returns true after the raster scale is reset to 1.0 - is that the right place?).

However working with sunxd@ I did find that it does NOT appear to reproduce (at least not as severely, I can't notice it) with *either* of the following flags set:

i. --disable-gpu

ii. --disable-mac-overlays

cc-ing ccameron@ on suggestion of sunxd@ - Christopher, do you have any input onto what might be wrong here?

Using --disable-mac-overlays means that our GL renderer is drawing this differently than CoreAnimation.

Do any of these layers have fractional alignment? It could be that CA and GL draw those differently.