I am sorry, the URL was wrong, correct URL is:

https://goo.gl/wLWgDp

To avoid confusion:

URL to the test page is: https://goo.gl/wLWgDp

And you have to use 'google' for username and 'dev' for password (both without single quotes) :)

Blurriness seems like a paint issue to me? Changing component to Blink>Paint

Able to reproduce the issue on windows 10 & 7 , ubuntu 14.04 and mac os 10.12.5 using chrome M60 #60.0.3112.78 and canary M62 #62.0.3173.2 .

This is a regression issue broken in M51 .

Using the per-revision bisect providing the bisect results,
Good build: 51.0.2694.0 (Revision: 383878).
Bad build: 51.0.2696.0 (Revision: 384437).

You are probably looking for a change made after 384056 (known good), but no later than 384058 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspectas some perf builds might get missing due to failure.

 https://chromium.googlesource.com/chromium/src/+log/be0116796008e81aa179f6e41fe05f5225ff1c6a..9174f59cb6a861a48f89aff2fd89d2f07a832e0a

Suspect : https://chromium.googlesource.com/chromium/src/+/9174f59cb6a861a48f89aff2fd89d2f07a832e0a

From the CL above, assigning the issue to the concern owner 

@chrishtr- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review URL: https://codereview.chromium.org/1835833005

Thanks!

This is probably WontFix. The blamed change affects what content gets what layers and presumably now the rotated content is getting its own layer when maybe before it wasn't. Hence the rotation is only applied to the actually rotated content.

Note to the reporter. The blurriness is due to the compositor's behavior on composited layers. The layer is rendered without the rotation and then rotated. The re-sampling associated with the rotation causes it to blur. It may also be due to sub-pixel text rendering being on or off for different layers.

I am not sure if I understand correct. But please have a look to the above screenshot.

Chrome should be able to do it without blurriness or am I wrong? Otherwise the feature 'rotate' would be freakish and I personally would have to avoid using it.

Deleted: rotate.png 167 KB

	rotate.png 167 KB View Download

Ultimately we are trading off speed for quality. Transforms are frequently used in animated content where it is important to paint fast, and less important to render at highest quality. Firefox might be making different trade-offs or using different re-sampling methods. We do tend to be a bit blurry in my opinion.

I understand your argument. For animations it is fully correct as they do not need to be sharpened while animating. What I do not understand is the inconsistency because most get sharpened (please have a look to the logo of the page which is rotated but very nice sharpened) but the footer area is extremely blurry (look at the red debug info).

Transformations are also used for static contents. If there is a technical reason that hinder consistency, is there a filter/option for static contents to initiate the final sharpening event? Like '-x-chrome-filter: resharpen'?

For text in particular, avoiding post-rasterization transforms is important for readability.  Text looks good iff Skia rasterizes with the correct/final CTM (modulo integral translations).

In this case, I believe schenney's analysis is correct: the content is rasterized without rotation into its own layer, and then transformed during compositing.  This is super bad for text - not only we destroy any hinting during post-transformation filtering, but the layerization also seems to disable subpixel rendering.

I tend to agree with the reporter though, in that this layerization choice doesn't make sense for static content -- plus it appears to be a regression.

And as I understand it right Chrome also uses the "periods of rest" to sharpen the rotated contents so there shouldn't be any performance issue.

So if you look at the other rotated texts and the graphic svg logo which are sharp you will see them first to be blurry when you visit the page and then sharpened after about 500 ms (roughly estimated). However the blurry contents in the footer seem to be quite forgotten.

Chrome did have a sharpness timer (called ImageQualityController internally) but it has been recently removed. We should now draw images with the same quality during and after animations.

In the current version or soon? Because currently during the animation it is blurry. It is sharpened 500-1000ms after animation has ended:

Have a look to the logo animation:

https://goo.gl/wLWgDp

Username: google
Password: dev

The sharpness timer / ImageQualityController was removed in Chrome 61 which is currently in Dev and Canary channels only. It was paired with a change to always use the high quality resize code so it should be a strict improvement. I just wanted to note that it was removed since you mentioned it; I don't think that change is related to the blurriness in this bug.

Ah okay, thank you for the information!

> always use the high quality resize code

Does this mean it actually rasterizes using the correct (full and final) transformation while animating or that it rasterizes at some nominal transform and then uses a "high quality" raster transform? I'm interested, because in general a "high quality" raster transform will look even worse (more blurry) for text than a "low quality" one.

@bungeman, the 500ms snapping that backeschwein noticed was just for images and was because because we previously switched resampling algorithms during animations. The raster scale decision (good or bad) has not changed.

For animations in general, I think we the raster scale is set to the scale of the beginning or end of the animation, whichever is larger.

The 1deg rotation layer is composited because of
https://codereview.chromium.org/1835833005, which turns off squashing for
non-2D translation transform.

At the time, this was because it was too hard to implement the correct semantics
for interest rects, but now that SPInvalidation has launched, I think it
is straightforward. Will give it a go.

Decreasing to Pri-2 though, because this is not a stable regression from M60.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/707023d380f9c090b21bce9d0f4cb502cce2858a

commit 707023d380f9c090b21bce9d0f4cb502cce2858a
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Tue Sep 12 02:36:14 2017

Fix interest rect computation for squashed layers under transform.

Instead of using one of the squashed layers as the starting point, use
the transformed ancestor, from which we have already computed an offset
to the squashing layer.

As a result, remove the squashing-prevention rule about non-translation
transforms.

Bug:  750433 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I4cf1fc5a2e34d7e40023d4c3481bb517c3b6e72f
Reviewed-on: https://chromium-review.googlesource.com/658335
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501157}
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/LayoutTests/compositing/layer-creation/overlap-animation-container-expected.txt
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/LayoutTests/compositing/squashing/dont-squash-with-scale-transform.html
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/LayoutTests/compositing/squashing/squash-transform-expected.txt
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/LayoutTests/compositing/squashing/squash-transform-repainting-child-expected.txt
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/LayoutTests/compositing/squashing/squash-transform-repainting-transformed-child-expected.txt
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.h
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/Source/core/paint/compositing/CompositingLayerAssigner.cpp
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/Source/platform/graphics/SquashingDisallowedReasons.cpp
[modify] https://crrev.com/707023d380f9c090b21bce9d0f4cb502cce2858a/third_party/WebKit/Source/platform/graphics/SquashingDisallowedReasons.h

It seems the bug has came back after the recent update.

If the bug has returned after being absent, please open a new issue.