Tested the same on Linux 14.04 chrome version 55.0.2868.0 and the output is as shown in the screenshot
Could you please let us know if this is the issue you are facing?
Deleted:
Screenshot from 2016-09-22 17:19:00.png
26.3 KB
Yes this is the issue. The image should appear crisper. See this screenshot
for how it should look. I manually bisected also, and it seems blurry at all
revisions. Will debug with Vlad today.
It seems that the problem is that we scale the image using high filter quality to the nearest integer boundary. Then, we pass that to Skia with low filter quality which causes blurriness when scaling to precise subpixel scale.
FWIW, using medium filter quality produces much better results here (with a small bugfix which I'll upload shortly). I don't think we should actually switch to medium filter quality, since that can produce worse results in other cases.
Florin, I think you looked at a similar bug in the past. Do you have any thoughts here? What was the outcome from the other bug?
I used the attached page to test this, since if we fix 0.48 scale, then we might break something like 0.47 scale.
Also, I've tried other high filter quality algorithms in Skia and the results are all very similar.
(Interestingly, if I capture the SKP either in about://tracing or printToSkPicture, it looks much better. I guess the capture bypasses IDC? It would be nice to plumb IDC on the capture path also, to help debugging this sort of thing.)
Based on prev bugs my first thought was this is hitting the unaligned layer problem (layer gets post-filtered due to subpixel positionig), but that does't seem to be the case.
So I agree, it looks like bilerp-on-top-of-hq is causing this degradation. I'm guessing that for certain residual scales (close to midpoint?) it yields worse results.
Previously (the bug I think vmpstr is referring to), I tried using nearest neighbor instead of bilerp for the second pass to avoid blurring. It works in the sense that the result is sharper, but it introduces unacceptable geometrical artifacts (noticeable stretches, non-contiguous animations). So no go.
As long as we're filtering twice (bilerp on top of discretized bicubics), I don't think there's a good answer to this.
One interesting question is why does the capture look so much better? Skia should have the same issue (its hq scaled image cache is also int-snapped), so it should have the same problem.
I believe the difference is in how we treat downscaling: Skia doesn't use bicubic but mip maps for hq downscaling, while it sounds like IDC is sticking to bicubic for both up/down scaling. So when downscaling, Skia does the equivalent of kMedium - which you've already mentioned produces better results.
Would it be an acceptable workaround for IDC to adopt the same heuristic as Skia (use mip maps for hq downscaling)? Of course the problem remains for upscaling, but I suspect the effect is diminished because the relative stretch ratio due to int rounding decreases.
Then there's the author workaround of using "image-rendering:-webkit-optimize-contrast;" - which forces bilerp-only, and AFAIK is the only guaranteed technique for crisp AND contiguous animations.
It's a pretty easy change for us to use medium filter quality for downscales. If that's the thing Skia is using anyway, then let's just do that. I'll put up a patch.
As an additional point here, GPU raster only uses mips and it seems that it produces acceptable results (from the lack of bug reports on systems that have this enabled).
Yeah, Skia falls back to kMedium when downscaling: https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkBitmapController.cpp?rcl=0&l=111
Come to think of it, if we agree that double-filtering is Bad, maybe we should consider always avoiding it? Are there any cases where bicubic + bilerp looks better than kMedium, or even plain kLow?
Should we only do HQ when the dest geometry is pixel aligned AND is not animating?
That second bit it tricky, but likely important (to avoid popping in-and-out of HQ during animations). Quick test for the first part, to see what blows up: https://codereview.chromium.org/2363643003/
Tested the same on win10, mac 10.11.6 and Linux 14.04 using chrome version 55.0.2873.0 with example in comment #1 - Observed that the image is still not crisper
Please find the screenshot
vmpstr@, Could you please confirm on the fix in comment #17
Comment #17 is not the fix, I'm just fixing some tests so that I can land the fix. The next patch on this bug should be the fix, I'm planning on landing it ASAP.
Tested the feature on win10 mac 10.11.6 and Linux 14.04 chrome version 54.0.2840.50 - Observed that the image is crisper
Please find the screenshot
Fix works as expected. Hence adding the TE-Verified labels
![https://s3-us-west-2.amazonaws.com/s.cdpn.io/59506/logo.png"/](https://s3-us-west-2.amazonaws.com/s.cdpn.io/59506/logo.png"/){kind=link}
Comment 1 by chrishtr@chromium.org
, Sep 21 2016