When calling cubicTo(a, b, c) and if the distance between fPrevPt and a
is too small, b is used instead of a to calculate the first tangent,
even if the distance between fPrevPt and b is too small.
In debug mode, this is causing an assertion to fail in
SkPathStroker::preJoinTo() and, in Release, the use of an
unitialized value.
The first patch set is adding a failing test.
The second one add the fix to SkPathStroker::cubicTo()
BUG=skia:2820
R=bsalomon@chromium.org, junov@chromium.org, reed@google.com, caryclark@google.com, bsalomon@google.com
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/460813002
Implement support for NV_path_rendering on OpenGL ES. Use
glProgramPathFragmentInputGenNV function call instead of glPathTexGenNV to
communicate transforms to fragment shader.
The intention is that the NVPR paths will be drawn with the same shader program
as non-NVPR geometry. For NVPR calls, the GPU will skip the vertex shader and
just run the fragment shader.
After program is linked, query the locations of the fragment shader inputs with
glGetResourceLocation. The location will be used to set the transforms with
glProgramPathFragmentInputGenNV.
The functions and their workings are documented in:
glProgramPathFragmentInputGenNV
https://www.opengl.org/registry/specs/NV/path_rendering.txt
(note: addition as of API version 1.3)
glGetResourceLocation
https://www.opengl.org/registry/specs/ARB/program_interface_query.txthttp://www.opengl.org/registry/doc/glspec44.core.pdf
(function is in core Open GL 4.4)
Note: glProgramPathFragmentInputGenNV could be used also for OpenGL. However,
using seems to trigger a bug in the driver. Disable this feature on OpenGL at
least until the driver is fixed and released. The bug manifests in shadertext
test, where the lower-left text pair is missing. Valgrind catches a bad read
for the test and causes the context to OOM reproducibly.
R=bsalomon@google.com, cdalton@nvidia.com, joshualitt@google.com, joshualitt@chromium.org
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/367643004
morphology, blur.
[Reland with fixed tests.]
Because we're computing "backwards" from a clip rect of destination
pixels to be filled to the required source pixels, we should use tail
recursion rather than head recursion in onFilterBounds().
This actually only makes a difference for drop-shadow, where
the computation is non-commutative. Blur and morphology commute, but I
moved them to tail recursion anyway for clarity (so all onFilterBounds
use tail recursion).
BUG=skia:
R=bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/481273005
Reason for revert:
This CL is currently breaking the Win7 and Win8 bots on some of the new tests (in DM).
Original issue's description:
> Fix recursive computation of filter bounds for drop shadow,
> morphology, blur.
>
> Because we're computing "backwards" from a clip rect of destination
> pixels to be filled to the required source pixels, we should use tail
> recursion rather than head recursion in onFilterBounds().
>
> This actually only makes a difference for drop-shadow, where
> the computation is non-commutative. Blur and morphology commute, but I
> moved them to tail recursion anyway for clarity (so all onFilterBounds
> use tail recursion).
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/28648fe4a69b0cee8df42b5966e4e645c3aabefbR=bsalomon@google.com, senorblanco@chromium.orgTBR=bsalomon@google.com, senorblanco@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: djsollen@google.com
Review URL: https://codereview.chromium.org/504773003
morphology, blur.
Because we're computing "backwards" from a clip rect of destination
pixels to be filled to the required source pixels, we should use tail
recursion rather than head recursion in onFilterBounds().
This actually only makes a difference for drop-shadow, where
the computation is non-commutative. Blur and morphology commute, but I
moved them to tail recursion anyway for clarity (so all onFilterBounds
use tail recursion).
BUG=skia:
R=bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/481273005
In SkBBoxHierarchyRecord:
Since the bounds we pass to saveLayer are in the pre-filtering
coordinate space, they aren't correct for determining the actual
device pixels touched by the saveLayer in this case.
The easiest fix for now is to pass the clip bounds, since the final
draw done in restore() will never draw outside the clip.
In SkRecordDraw:
We do adjust the bounds passed to saveLayer, so we just need to make
sure that when we're using a paint that may affect transparent black,
we ignore the calculated bounds of draw ops and use the clip intersected
with those adjusted bounds.
See originally crrev.com/497773002
BUG=skia:
R=reed@google.com, senorblanco@chromium.org, junov@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/496963003
