The second image I add is how it should look and how it looks on firefox.

Able to reproduce on Windows-10 HiDpi and Mac OS 10.12.6 using chrome latest stable #60.0.3112.101. This issue is not observed on Ubuntu 14.04

Bisect Information:
---------------------
Good build: 60.0.3074.0 (465085)
Bad Build : 60.0.3074.0 (465838)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/14d57a734d7f70b2087ed8db3b833c47d3c7df13..8e75e9c587155933fe3e775605e18111a6cc2b9c

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2784683002

senorblanco@ - 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. Adding RB-Stable since this is a latest regression observed on M-60, please feel free to edit if this is not the case.

Thanks!

Note: this problem doesn't seem to be due to the tessellating path renderer specifically, but GPU rasterization being enabled. If I disable the TPR in the PR chain, the problem still occurs. (Strangely, if I comment out *all* the path renderers, it works. So perhaps it's something common to all the path renderers?)

In non-MSAA mode, it seems that the GrAAConvexPathRenderer is to blame -- if I comment it out, the problem goes away. Not sure what's going on in MSAA mode yet.

Brian, could you take a look / reassign?

Hey Stephen, I'm pretty sure this is the tessellating path renderer. I can reproduce when running with --gpu-rasterization-msaa-sample-count=8 but not with =0.

I grabbed a skp and can reproduce this in the Skia viewer app only when the tessellating path renderer is enabled (attached skia patch that disables the other PRs). I'm reproducing by running viewer like this on linux:

viewer -b gl --skps . --match layer_0 --msaa 8

Deleted: pr.diff 2.8 KB

pr.diff 2.8 KB Download

Deleted: layer_0.skp 818 KB

layer_0.skp 818 KB Download

I also meant to add that when reproducing in Chrome with msaa the repro was flaky. If I panned and zoomed around enough I could get it. In viewer I was getting a repro in the first frame rendered every time, though YMMV.

Hmm. I still see it with the tessellating path renderer completely commented out in the code, both in MSAA and non-MSAA modes. I also enabled logging in the TPR and nothing is being logged.

I'm pretty sure at least that the GrAAConvexPathRenderer is to blame in non-MSAA mode, but I'm not sure what's going on in MSAA mode. I'll look some more into that case.

One more datapoint: I bisected the failure in non-MSAA mode back to at least r338804 (before which the tab crashes so I wasn't able to go further), which was before the TPR was enabled for non-MSAA.

Ok, maybe there are two different bugs. I'll try to repro some more without msaa.

Yeah, we may be talking about different bugs. I was referring to the large missing green areas when you let the link in the original report "settle" to its final zoom (i.e., the big green area in the second screen shot above, which is missing with GPU raster on).

There are also the extra lines on the stroked region in the SKP in #8.

However, both seem to still repro when the TPR is commented out.

Some more datapoints: in MSAA mode on Linux, the SKP seems to be drawing in the stencil-and-cover PR. Its failure mode with *only* the default or tessellating path renderer enabled is different (and worse) than the failure mode with the SACPR enabled, but the same as each other. So I'm speculating that it might be a problem with the stroking of the path before it's passed to the PRs.

With all PRs disabled, the problem goes away.

I see, I wasn't quoting the URL at the command line so I wasn't getting the right view on the map.

This SKP reproduces the convex path renderer bug

Deleted: layer_0.skp 746 KB

layer_0.skp 746 KB Download

So this is not the same as https://bugs.chromium.org/p/chromium/issues/detail?id=754293, now blocked on https://bugs.chromium.org/p/chromium/issues/detail?id=756823?

It does not appear to be.

Simplified skp that draws a single path attached.

Deleted: simplified.skp 440 bytes

simplified.skp 440 bytes Download

The issue is that there are paths that are determined to be convex that are not actually convex. It seems to be related to paths with small coordinate values (projected to a significant area by a matrix on the canvas).

Here's a Skia repro of the stroking artifact. Repros w/--msaa 4 --pr tess (or --pr grdefault) on my machine.

Deleted: bug-755839-repro.patch 68.3 KB

bug-755839-repro.patch 68.3 KB Download

Also repros w/--pr msaa

Reduction of #20.

Deleted: bug-755839-repro.patch 2.5 KB

bug-755839-repro.patch 2.5 KB Download

I've opened Skia bug https://bugs.chromium.org/p/skia/issues/detail?id=6987 for the stroker problem, so we can keep this one for the convexity issue.

My fix for the stroking issue has landed, and it seems to have fixed the filled path issue too (the original repro URL above).

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/c8323aa51ab27259076532ba081d2ed5c26aedfc

commit c8323aa51ab27259076532ba081d2ed5c26aedfc
Author: Cary Clark <caryclark@skia.org>
Date: Fri Aug 25 14:40:47 2017

tiny concave path point fix

The tiny path added to PathTest.cpp has
tinier cross products (e.g. 1e-12)
so appears to be a series of unbending
lines as far as getConvexity is concerned.

This point fix looks for paths that
do not bend left or right or go backwards,
but do have a bounds, and calls them
concave.

A better fix may be to consider empty
and degenerate paths to be concave
instead of convex; I don't know if
anyone relies on the existing behavior.

Another better fix may be to change
the math to compute the path turns
even though the numbers are very small;
on the surface, very difficult.

R=bsalomon@google.com,reed@google.com
Bug:755839
Change-Id: Ie2280f3f0b95fecab2899f5fc579fd39258e0647
Reviewed-on: https://skia-review.googlesource.com/38720
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>

[modify] https://crrev.com/c8323aa51ab27259076532ba081d2ed5c26aedfc/tests/PathTest.cpp
[modify] https://crrev.com/c8323aa51ab27259076532ba081d2ed5c26aedfc/src/core/SkPath.cpp

Was the issue solved? or the changes haven't go live? I'm still seeing the issue on the latest chrome version on Mac OS. Link to repro: http://senhfedecnr.surge.sh/maps/projections?municipality=Monterrey&state=Nuevo%20Le%C3%B3n

Thank you

Re: #26: it should be fixed in the next Stable release. If you want to verify early, you can try Chrome Canary (it'll install alongside your Stable install): https://www.google.com/chrome/browser/canary.html

It is working great in Canary, it feels faster too. Thank you guys!

I tested it on the latest stable release (61) and it is not working fine (repro link: http://senhfedecnr.surge.sh/maps/projections?municipality=Monterrey&state=Nuevo%20Le%C3%B3n), an issue with the stroke is fixed but still has some transparent fill objects when the fill has a color, anyhow it works fine on canary, does that means it will be fixed on the next stable release? 

Also, I found another Issue (pic attached and same repro link), the map key boxes have some colors mixed and when inspected the setted colors are fine, it also behaves weirdly when I navigate through the map, and the map key doesn't involve svgs, just normal divs. This didn't happen in chrome version 60 and the repro link hasn't been modified.

The red map shows the issue of transparent objects that is not present in canary, but present in this stable release, and other picture is the issue with the map key which is present in both this stable release and canary.

Tested in Mac OS 10.11.

Thank you.

Deleted: Screen Shot 2017-09-07 at 10.45.08 PM.png 2.3 MB

	Screen Shot 2017-09-07 at 10.45.08 PM.png 2.3 MB View Download

Deleted: Screen Shot 2017-09-07 at 10.53.59 PM.png 279 KB

	Screen Shot 2017-09-07 at 10.53.59 PM.png 279 KB View Download

The fixes landed after the branch for M61 was cut, so you won't see them in that release. They'll likely be in M62.

I'd go ahead and log a new bug for the new issue (the map key issue). That way, we can track it independently. Thanks!