New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 593049 link

Starred by 1 user
Status: Fixed
Owner:
█ caryclark@google.com
Last visit > 30 days ago
Closed: Mar 2016
Cc:
rmis...@chromium.org
█ rnimmagadda@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Canvas incorrectly renders arc with lineCap

Reported by steele.p...@gmail.com, Mar 8 2016 
Chrome Version: 49.0.2623.75 m (64-bit)
URL: http://phetsims.github.io/scenery/tests/browsers/chrome-arc-line-cap.html
Other browsers tested:

     Safari: 9.0.3        OK
    Firefox: 44.0.2       OK
       Edge: 25.10586.0.0 OK

Code to reproduce the problem on Chrome:

var canvas = document.createElement( 'canvas' );
var context = canvas.getContext( '2d' )
canvas.width = 220;
canvas.height = 220;
context.setTransform( 1, 0, 0, 1, -151, -440 );
context.transform( 0.6744791666666666, 0, 0, 0.6744791666666666, 259, 548.5911458333333 );
context.beginPath();
context.moveTo( -43.44464063610148, 79.43535936389853 );
context.arc( 0, 122.88000000000002, 61.44000000000001, -2.356194490192345, -0.7853981633974483, false );
context.strokeStyle = "black";
context.lineWidth = 15.360000000000003;
context.lineCap = "round";
context.stroke();
document.body.appendChild( canvas );

What is the expected result?
A round end to the stroke

What happens instead?
Canvas causes a truncated end

Screenshots of the stroke in Chrome (with the problem) and in Firefox (without the problem) below.
chrome-arc-line-cap.PNG
1.4 KB View Download
correct-arc-line-cap.PNG
1.6 KB View Download

Comment 1 by rnimmagadda@chromium.org, Mar 9 2016

Cc: rnimmagadda@chromium.org
Components: Blink>Rendering
Labels: M-50 OS-Linux OS-Mac OS-Windows
Owner: rmis...@chromium.org
Status: Assigned (was: Unconfirmed)
====================================

Good Build:

47.0.2494.0    Base Position: 345501


Bad Build:

47.0.2498.0    Base Position: 346531

=====================================

Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 49.0.2623.87

This is a regression issue broken in M47, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/2e31d26ba3287cba63824b0c43b0494b3afc6b61..4d54dcd25c60ada7ccacacb565bfe2b045e281ff

Suspecting Commit: 795b00b082a222016992ea45479412b903085cdb

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

@rmistry: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Comment 2 by rmis...@google.com, Mar 9 2016

Cc: rmis...@chromium.org
Owner: robertphillips@chromium.org
Assigning to the current sheriff to help investigate since I am OOO.

Comment 3 by robertphillips@chromium.org, Mar 9 2016

Cc: caryclark@chromium.org caryclark@google.com
Cary - could this be: https://codereview.chromium.org/1314213002 (zero-length cap fix)

Comment 4 by caryclark@google.com, Mar 9 2016

Cc: -caryclark@chromium.org -caryclark@google.com
Owner: caryclark@google.com

Comment 5 by robertphillips@chromium.org, Mar 9 2016 

I was able to reproduce (but not bisect) this in Skia. Here is the code I was using:

        canvas->translate(-151, -440);

        static const float kMat[9] = {
            0.6744791666666666f, 0, 259,
            0, 0.6744791666666666f, 548.5911458333333f,
            0, 0, 1
        };
        SkMatrix m;
        m.set9(kMat);

        canvas->concat(m);

        SkPath p;
        p.moveTo(-43.44464063610148f, 79.43535936389853f);

        static const float xOff = 0.0f;
        static const float yOff = 122.88f;
        static const float kRad = 61.44f;
        SkRect oval = SkRect::MakeXYWH(-kRad, yOff-kRad, 2*kRad, 2*kRad);
        p.arcTo(oval,
                1.25 * 180,
                .5 * 180,
                false);

        SkPaint paint;
        paint.setStyle(SkPaint::kStroke_Style);
        paint.setStrokeCap(SkPaint::kRound_Cap);
        paint.setStrokeWidth(15.36f);

        canvas->drawPath(p, paint);

Toggling off the round capping did make the path look at expected (i.e., correctly Butt capped).

Comment 6 by robertphillips@chromium.org, Mar 9 2016 

Note, the problem goes away when the initial "moveTo" is removed.
Project Member

Comment 7 by bugdroid1@chromium.org, Mar 16 2016 

The following revision refers to this bug:
  https://skia.googlesource.com/skia.git/+/1b6934fcd968cf7e2d931bea3eefcd05a168ec3d

commit 1b6934fcd968cf7e2d931bea3eefcd05a168ec3d
Author: caryclark <caryclark@google.com>
Date: Wed Mar 16 13:46:50 2016

skip stroke outset of all teeny lines

Allow a small amount of slop when seeing
if the previous moveTo and subsequent lineTo
are the same.

R=robertphillips@google.com
BUG= 593049 
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1805913002

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

[modify] https://crrev.com/1b6934fcd968cf7e2d931bea3eefcd05a168ec3d/gm/arcto.cpp
[modify] https://crrev.com/1b6934fcd968cf7e2d931bea3eefcd05a168ec3d/src/core/SkStroke.cpp

Comment 8 by caryclark@google.com, Mar 17 2016

Status: Fixed (was: Assigned)

Comment 9 by tkent@chromium.org, Mar 23 2016

Components: -Blink>Rendering Blink>Layout
►

Sign in to add a comment