Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright 2011 Google Inc.
|
|
|
|
|
*
|
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
|
* found in the LICENSE file.
|
|
|
|
|
*/
|
2019-05-01 21:28:53 +00:00
|
|
|
|
2019-04-23 17:05:21 +00:00
|
|
|
#include "gm/gm.h"
|
|
|
|
|
#include "include/core/SkCanvas.h"
|
2019-05-01 21:28:53 +00:00
|
|
|
#include "include/core/SkColor.h"
|
|
|
|
|
#include "include/core/SkFont.h"
|
2019-04-23 17:05:21 +00:00
|
|
|
#include "include/core/SkPaint.h"
|
|
|
|
|
#include "include/core/SkPath.h"
|
2019-05-01 21:28:53 +00:00
|
|
|
#include "include/core/SkPoint.h"
|
|
|
|
|
#include "include/core/SkRect.h"
|
|
|
|
|
#include "include/core/SkScalar.h"
|
|
|
|
|
#include "include/core/SkSize.h"
|
|
|
|
|
#include "include/core/SkString.h"
|
|
|
|
|
#include "include/core/SkTypeface.h"
|
|
|
|
|
#include "include/core/SkTypes.h"
|
2019-04-23 17:05:21 +00:00
|
|
|
#include "include/utils/SkRandom.h"
|
|
|
|
|
#include "tools/ToolUtils.h"
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
|
|
|
|
|
namespace skiagm {
|
|
|
|
|
|
|
|
|
|
class DegenerateSegmentsGM : public GM {
|
|
|
|
|
struct PathAndName {
|
|
|
|
|
SkPath fPath;
|
|
|
|
|
const char* fName1;
|
|
|
|
|
const char* fName2;
|
|
|
|
|
};
|
|
|
|
|
|
2019-07-18 16:36:54 +00:00
|
|
|
SkString onShortName() override { return SkString("degeneratesegments"); }
|
2012-08-23 18:14:13 +00:00
|
|
|
|
2019-07-18 16:36:54 +00:00
|
|
|
SkISize onISize() override { return {896, 930}; }
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
|
|
|
|
|
typedef SkPoint (*AddSegmentFunc)(SkPath&, SkPoint&);
|
2012-08-23 18:14:13 +00:00
|
|
|
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
// We need to use explicit commands here, instead of addPath, because we
|
2012-01-04 21:05:51 +00:00
|
|
|
// do not want the moveTo that is added at the beginning of a path to
|
|
|
|
|
// appear in the appended path.
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
static SkPoint AddMove(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.close();
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddDegenLine(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
path.lineTo(startPt);
|
|
|
|
|
return startPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveDegenLine(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.lineTo(moveToPt);
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveDegenLineClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.lineTo(moveToPt);
|
|
|
|
|
path.close();
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddDegenQuad(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
path.quadTo(startPt, startPt);
|
|
|
|
|
return startPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveDegenQuad(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.quadTo(moveToPt, moveToPt);
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveDegenQuadClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.quadTo(moveToPt, moveToPt);
|
|
|
|
|
path.close();
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddDegenCubic(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
path.cubicTo(startPt, startPt, startPt);
|
|
|
|
|
return startPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveDegenCubic(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.cubicTo(moveToPt, moveToPt, moveToPt);
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveDegenCubicClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.cubicTo(moveToPt, moveToPt, moveToPt);
|
|
|
|
|
path.close();
|
|
|
|
|
return moveToPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
path.close();
|
|
|
|
|
return startPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddLine(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint endPt = startPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.lineTo(endPt);
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveLine(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = moveToPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.lineTo(endPt);
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveLineClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = moveToPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.lineTo(endPt);
|
|
|
|
|
path.close();
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddQuad(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint midPt = startPt + SkPoint::Make(20*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = startPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.quadTo(midPt, endPt);
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveQuad(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
SkPoint midPt = moveToPt + SkPoint::Make(20*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = moveToPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.quadTo(midPt, endPt);
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveQuadClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
SkPoint midPt = moveToPt + SkPoint::Make(20*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = moveToPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.quadTo(midPt, endPt);
|
|
|
|
|
path.close();
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddCubic(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint t1Pt = startPt + SkPoint::Make(15*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint t2Pt = startPt + SkPoint::Make(25*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = startPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.cubicTo(t1Pt, t2Pt, endPt);
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveCubic(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
SkPoint t1Pt = moveToPt + SkPoint::Make(15*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint t2Pt = moveToPt + SkPoint::Make(25*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = moveToPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.cubicTo(t1Pt, t2Pt, endPt);
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static SkPoint AddMoveCubicClose(SkPath& path, SkPoint& startPt) {
|
|
|
|
|
SkPoint moveToPt = startPt + SkPoint::Make(0, 10*SK_Scalar1);
|
|
|
|
|
SkPoint t1Pt = moveToPt + SkPoint::Make(15*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint t2Pt = moveToPt + SkPoint::Make(25*SK_Scalar1, 5*SK_Scalar1);
|
|
|
|
|
SkPoint endPt = moveToPt + SkPoint::Make(40*SK_Scalar1, 0);
|
|
|
|
|
path.moveTo(moveToPt);
|
|
|
|
|
path.cubicTo(t1Pt, t2Pt, endPt);
|
|
|
|
|
path.close();
|
|
|
|
|
return endPt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void drawPath(SkPath& path, SkCanvas* canvas, SkColor color,
|
2011-12-20 21:48:14 +00:00
|
|
|
const SkRect& clip, SkPaint::Cap cap, SkPaint::Join join,
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
SkPaint::Style style, SkPath::FillType fill,
|
|
|
|
|
SkScalar strokeWidth) {
|
|
|
|
|
path.setFillType(fill);
|
|
|
|
|
SkPaint paint;
|
|
|
|
|
paint.setStrokeCap(cap);
|
|
|
|
|
paint.setStrokeWidth(strokeWidth);
|
2011-12-20 21:48:14 +00:00
|
|
|
paint.setStrokeJoin(join);
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
paint.setColor(color);
|
|
|
|
|
paint.setStyle(style);
|
|
|
|
|
canvas->save();
|
|
|
|
|
canvas->clipRect(clip);
|
|
|
|
|
canvas->drawPath(path, paint);
|
|
|
|
|
canvas->restore();
|
|
|
|
|
}
|
2012-08-23 18:14:13 +00:00
|
|
|
|
2019-07-18 16:36:54 +00:00
|
|
|
void onDraw(SkCanvas* canvas) override {
|
|
|
|
|
constexpr AddSegmentFunc gSegmentFunctions[] = {
|
|
|
|
|
AddMove,
|
|
|
|
|
AddMoveClose,
|
|
|
|
|
AddDegenLine,
|
|
|
|
|
AddMoveDegenLine,
|
|
|
|
|
AddMoveDegenLineClose,
|
|
|
|
|
AddDegenQuad,
|
|
|
|
|
AddMoveDegenQuad,
|
|
|
|
|
AddMoveDegenQuadClose,
|
|
|
|
|
AddDegenCubic,
|
|
|
|
|
AddMoveDegenCubic,
|
|
|
|
|
AddMoveDegenCubicClose,
|
|
|
|
|
AddClose,
|
|
|
|
|
AddLine,
|
|
|
|
|
AddMoveLine,
|
|
|
|
|
AddMoveLineClose,
|
|
|
|
|
AddQuad,
|
|
|
|
|
AddMoveQuad,
|
|
|
|
|
AddMoveQuadClose,
|
|
|
|
|
AddCubic,
|
|
|
|
|
AddMoveCubic,
|
|
|
|
|
AddMoveCubicClose
|
|
|
|
|
};
|
|
|
|
|
const char* gSegmentNames[] = {
|
|
|
|
|
"Move",
|
|
|
|
|
"MoveClose",
|
|
|
|
|
"DegenLine",
|
|
|
|
|
"MoveDegenLine",
|
|
|
|
|
"MoveDegenLineClose",
|
|
|
|
|
"DegenQuad",
|
|
|
|
|
"MoveDegenQuad",
|
|
|
|
|
"MoveDegenQuadClose",
|
|
|
|
|
"DegenCubic",
|
|
|
|
|
"MoveDegenCubic",
|
|
|
|
|
"MoveDegenCubicClose",
|
|
|
|
|
"Close",
|
|
|
|
|
"Line",
|
|
|
|
|
"MoveLine",
|
|
|
|
|
"MoveLineClose",
|
|
|
|
|
"Quad",
|
|
|
|
|
"MoveQuad",
|
|
|
|
|
"MoveQuadClose",
|
|
|
|
|
"Cubic",
|
|
|
|
|
"MoveCubic",
|
|
|
|
|
"MoveCubicClose"
|
|
|
|
|
};
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
|
|
|
|
|
struct FillAndName {
|
|
|
|
|
SkPath::FillType fFill;
|
|
|
|
|
const char* fName;
|
|
|
|
|
};
|
2016-09-01 18:24:54 +00:00
|
|
|
constexpr FillAndName gFills[] = {
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
{SkPath::kWinding_FillType, "Winding"},
|
|
|
|
|
{SkPath::kEvenOdd_FillType, "Even / Odd"},
|
|
|
|
|
{SkPath::kInverseWinding_FillType, "Inverse Winding"},
|
|
|
|
|
{SkPath::kInverseEvenOdd_FillType, "Inverse Even / Odd"}
|
|
|
|
|
};
|
|
|
|
|
struct StyleAndName {
|
|
|
|
|
SkPaint::Style fStyle;
|
|
|
|
|
const char* fName;
|
|
|
|
|
};
|
2016-09-01 18:24:54 +00:00
|
|
|
constexpr StyleAndName gStyles[] = {
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
{SkPaint::kFill_Style, "Fill"},
|
|
|
|
|
{SkPaint::kStroke_Style, "Stroke 10"},
|
|
|
|
|
{SkPaint::kStrokeAndFill_Style, "Stroke 10 And Fill"}
|
|
|
|
|
};
|
|
|
|
|
struct CapAndName {
|
2011-12-20 21:48:14 +00:00
|
|
|
SkPaint::Cap fCap;
|
|
|
|
|
SkPaint::Join fJoin;
|
|
|
|
|
const char* fName;
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
};
|
2016-09-01 18:24:54 +00:00
|
|
|
constexpr CapAndName gCaps[] = {
|
2011-12-20 21:48:14 +00:00
|
|
|
{SkPaint::kButt_Cap, SkPaint::kBevel_Join, "Butt"},
|
|
|
|
|
{SkPaint::kRound_Cap, SkPaint::kRound_Join, "Round"},
|
|
|
|
|
{SkPaint::kSquare_Cap, SkPaint::kBevel_Join, "Square"}
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
SkPaint titlePaint;
|
|
|
|
|
titlePaint.setColor(SK_ColorBLACK);
|
|
|
|
|
titlePaint.setAntiAlias(true);
|
2019-03-20 16:12:10 +00:00
|
|
|
SkFont font(ToolUtils::create_portable_typeface(), 15);
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
const char title[] = "Random Paths Drawn Into Rectangle Clips With "
|
|
|
|
|
"Indicated Style, Fill and Linecaps, "
|
|
|
|
|
"with Stroke width 6";
|
2019-01-07 16:01:57 +00:00
|
|
|
canvas->drawString(title, 20, 20, font, titlePaint);
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
|
2014-12-15 20:54:51 +00:00
|
|
|
SkRandom rand;
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
SkRect rect = SkRect::MakeWH(220*SK_Scalar1, 50*SK_Scalar1);
|
|
|
|
|
canvas->save();
|
|
|
|
|
canvas->translate(2*SK_Scalar1, 30 * SK_Scalar1); // The title
|
|
|
|
|
canvas->save();
|
|
|
|
|
unsigned numSegments = SK_ARRAY_COUNT(gSegmentFunctions);
|
|
|
|
|
unsigned numCaps = SK_ARRAY_COUNT(gCaps);
|
|
|
|
|
unsigned numStyles = SK_ARRAY_COUNT(gStyles);
|
|
|
|
|
unsigned numFills = SK_ARRAY_COUNT(gFills);
|
2011-12-20 21:48:14 +00:00
|
|
|
for (size_t row = 0; row < 6; ++row) {
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
if (0 < row) {
|
|
|
|
|
canvas->translate(0, rect.height() + 100*SK_Scalar1);
|
|
|
|
|
}
|
|
|
|
|
canvas->save();
|
2011-12-20 21:48:14 +00:00
|
|
|
for (size_t column = 0; column < 4; ++column) {
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
if (0 < column) {
|
|
|
|
|
canvas->translate(rect.width() + 4*SK_Scalar1, 0);
|
|
|
|
|
}
|
2012-08-23 18:14:13 +00:00
|
|
|
|
2019-03-20 16:12:10 +00:00
|
|
|
SkColor color = ToolUtils::color_to_565(0xff007000);
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
StyleAndName style = gStyles[(rand.nextU() >> 16) % numStyles];
|
|
|
|
|
CapAndName cap = gCaps[(rand.nextU() >> 16) % numCaps];
|
|
|
|
|
FillAndName fill = gFills[(rand.nextU() >> 16) % numFills];
|
|
|
|
|
SkPath path;
|
|
|
|
|
unsigned s1 = (rand.nextU() >> 16) % numSegments;
|
|
|
|
|
unsigned s2 = (rand.nextU() >> 16) % numSegments;
|
|
|
|
|
unsigned s3 = (rand.nextU() >> 16) % numSegments;
|
|
|
|
|
unsigned s4 = (rand.nextU() >> 16) % numSegments;
|
|
|
|
|
unsigned s5 = (rand.nextU() >> 16) % numSegments;
|
|
|
|
|
SkPoint pt = SkPoint::Make(10*SK_Scalar1, 0);
|
|
|
|
|
pt = gSegmentFunctions[s1](path, pt);
|
|
|
|
|
pt = gSegmentFunctions[s2](path, pt);
|
|
|
|
|
pt = gSegmentFunctions[s3](path, pt);
|
|
|
|
|
pt = gSegmentFunctions[s4](path, pt);
|
|
|
|
|
pt = gSegmentFunctions[s5](path, pt);
|
|
|
|
|
|
|
|
|
|
this->drawPath(path, canvas, color, rect,
|
2011-12-20 21:48:14 +00:00
|
|
|
cap.fCap, cap.fJoin, style.fStyle,
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
fill.fFill, SK_Scalar1*6);
|
|
|
|
|
|
|
|
|
|
SkPaint rectPaint;
|
|
|
|
|
rectPaint.setColor(SK_ColorBLACK);
|
|
|
|
|
rectPaint.setStyle(SkPaint::kStroke_Style);
|
|
|
|
|
rectPaint.setStrokeWidth(-1);
|
|
|
|
|
rectPaint.setAntiAlias(true);
|
|
|
|
|
canvas->drawRect(rect, rectPaint);
|
|
|
|
|
|
|
|
|
|
SkPaint labelPaint;
|
|
|
|
|
labelPaint.setColor(color);
|
|
|
|
|
labelPaint.setAntiAlias(true);
|
2019-01-07 16:01:57 +00:00
|
|
|
font.setSize(10);
|
|
|
|
|
canvas->drawString(style.fName, 0, rect.height() + 12, font, labelPaint);
|
|
|
|
|
canvas->drawString(fill.fName, 0, rect.height() + 24, font, labelPaint);
|
|
|
|
|
canvas->drawString(cap.fName, 0, rect.height() + 36, font, labelPaint);
|
|
|
|
|
canvas->drawString(gSegmentNames[s1], 0, rect.height() + 48, font, labelPaint);
|
|
|
|
|
canvas->drawString(gSegmentNames[s2], 0, rect.height() + 60, font, labelPaint);
|
|
|
|
|
canvas->drawString(gSegmentNames[s3], 0, rect.height() + 72, font, labelPaint);
|
|
|
|
|
canvas->drawString(gSegmentNames[s4], 0, rect.height() + 84, font, labelPaint);
|
|
|
|
|
canvas->drawString(gSegmentNames[s5], 0, rect.height() + 96, font, labelPaint);
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
}
|
|
|
|
|
canvas->restore();
|
|
|
|
|
}
|
|
|
|
|
canvas->restore();
|
|
|
|
|
canvas->restore();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
2019-01-23 15:22:01 +00:00
|
|
|
DEF_GM( return new DegenerateSegmentsGM; )
|
Modifying SkPath to store all verbs provided by the user, and to give
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-12-20 15:14:18 +00:00
|
|
|
|
|
|
|
|
}
|
