I can't reproduce this on ToT nor with Version 57.0.2957.0 (Official Build) canary (64-bit).

Do you see the problem in any other recent version?

I tried different versions and the problem reproduces every time. 

Another thing I noticed is that the problem reproduces only if I launch Chromium from the command line (Chromium.app/Contents/MacOS/Chromium), but if I double click Chromium.app in Finder, the problem is gone and the picture scales correctly.

I also ran tools/bisect-builds.py and got this result:

You are probably looking for a change made after 424263 (known good), but no later than 424275 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/b7c3f49d73334795c7e836874d75dbdb40edfd57..d01327c0e9a7bff6ad8ddd4eb6035c0fff729a14

I forgot to mention that I tried reproducing this bug on several MacBook Pros, and on some of them the bug exists, and on others it doesn't, but MacBook Pro models and MacOS versions are the same on them.

Thanks. I'll try to verify on a bunch of different configurations when I next get a chance.

I can't reproduce either on a MacBook Pro with M57 or M55.

Are there differences in the GPU settings recorded at about:gpu for those machines?

No, there are no differences at chrome://gpu
On my MacBook Pro everything is fine.
Bug in GPU rasterization SVG paths.

Unable to reproduce the issue on Mac 10.12.2 using latest Canaray#57.0.2966.0 as per steps mentioned in Comment#0.

Heart image rendered properly even we zoom out or zoom in.

Reporter@

Please upgrade to the latest Canary version & let us know your observations if still issue persists.

Please find the attached screencast for reference.

Thank you.

Deleted: 677024-Mac.mp4 1.1 MB

	677024-Mac.mp4 1.1 MB View Download

Downloaded the latest Canary version, I can reproduce the bug in it.

It is still present only if I launch Chrome via command line (by running /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary). 
If I launch Chrome by clicking an icon in Launchpad or by double clicking an icon in Finder, the bug goes away.

I've attached about:gpu info.
Screencast: https://yadi.sk/i/1Qdnmklq35tar2

Deleted: about_gpu.htm 50.3 KB

about_gpu.htm 50.3 KB View Download

Looks like the problem is in Skia, more specifically in `SkSL::stod` function. It uses `atof`, which is locale dependent and on my system it expects a comma as a decimal separator. Because of this every floating point value in every SkSL shader is read incorrectly and the resulting GLSL shader has incorrect values.
I have created a CL with a fix: https://skia-review.googlesource.com/c/6500/

Ethan, can you take a look? There's a patch above thanks to the Yandex folks.

I'm wondering if we're not putting a GrAutoLocaleSettings on the stack in this code path or if we are but it isn't setting the locale correctly. We should be setting the locale before calling the compiler in GrGLProgramBuilder::CreateProgram by instantiating a GrAutoLocaleSetter, but clearly that isn't working on your system. I'd be curious to know why in case there is a larger problem that needs to be fixed. 

Regardless of whether there's a larger issue to be fixed in Skia, the compiler can run standalone and thus this patch looks like a reasonable change to make.

The fix has been merged into Skia as https://skia-review.googlesource.com/c/6532/. It should roll into Chrome soon.

It seems there is indeed a problem with `GrAutoLocaleSetter`. The `newlocale` call to create a locale should have `LC_ALL_MASK` as a first parameter, according to documentation ([1], [2]), but `LC_ALL` is used instead.
This CL has a fix: https://skia-review.googlesource.com/c/6780/

[1] https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/newlocale.3.html
[2] http://man7.org/linux/man-pages/man3/newlocale.3.html

The issue with xlocale is that we were passing "C" to set the C locale (which works with posix) instead of nullptr. This was fixed here: https://skia-review.googlesource.com/c/6603/. The fix was associated with another similar bug, but this one should be closed as well.

I've just updated my Chromium checkout and rebuilt Chromium. It has both my fix for `atof` and a fix with nullptr instead of "C" as an argument to `newlocale`, but now I have another bug which is reproduced the same way. The renderer process now crashes, and I have the following output in console: http://pastebin.com/sLDEkKTH
The full output is very large, so I just put the last lines there, but the problem is noticeable: the floats are written like 7,96875.0, which is again a problem with the locale. The fix from my previous comment (https://skia-review.googlesource.com/c/6780/) solves this problem.