Add a couple of utility functions to SkPaint that return the bounds
of glyphs between a pair of lines.
The common use case envisioned generates the edges of descenders
between the top and bottom bounds of an underline to allow computing
a stroke that skips those descenders.
The implementation stores a linked list in each glyph containing
the bounds of the lines parallel to the advance and the outermost
intersections within those bounds.
When the glyph cache is constructed, the glyph path is intersected
with the bounds and the extreme min and max values within the bounds
is added to an intercept.
Share the text to path iter to construct the data.
Make a half-hearted attempt to support vertical text; while the
vertical implementation is complete; surrounding code (e.g. paint
align) has short-comings with vertical.
R=fmalita@chromium.org, reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1654883003
Review URL: https://codereview.chromium.org/1654883003
Filters such as SkMatrixConvolutionImageFilter which use the
asFragmentProcessor() path were not correctly handling srcOffset.
It is correctly applied to the bounds, but the srcRect and dstRect
were computed from the pre-offset bounds.
The fix is to move them to just above where they're used in drawing.
Note: this change adds a new test case to the imagefiltersgraph GM,
so it will have to be rebaselined post-landing.
BUG=skia:4855
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1637443003
Review URL: https://codereview.chromium.org/1637443003
Uses textureSize() to unnormalize texture coords when reading from a RECTANGLE texture. Because of this we also require a later GLSL version to use rectangle textures (1.40).
Note that this causes a issue with the bicubic effect. The texture coords seem to have poor precision and the result is ugly. textureSize() is intended as a workaround until effects can be updated to handle unnormalized coords themselves.
Updates places where we were looking for OpenGL version 3.2 for rectangle support. It was actually added in 3.1.
BUG=skia:3868
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1594483003
Review URL: https://codereview.chromium.org/1594483003
SkAlphaThresholdFilter was always allocating a mask texture
of the same size as the source texture. In addition to
potentially wasting VRAM, this could cause the mask to be
offset from the source texture, if the resulting bounds
were a different size than the source texture.
The fix is to allocate a mask texture only as large as the
bounds, and to offset it to the bounds origin on draw.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1609573002
Review URL: https://codereview.chromium.org/1609573002
Path measure cannot use the same code approach for quadratics
and cubics. Subdividing cubics repeatedly does not result in
subdivided t values, e.g. a quarter circle cubic divided in
half twice does not have a t value equivalent to 1/4.
Instead, always compute the cubic segment from a pair of
t values.
When finding the length of the cubic through recursive measures,
it is enough to carry the point at a given t to the next
subdivision.
(Chrome suppression has landed already.)
R=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1602153002
Review URL: https://codereview.chromium.org/1602153002
The GPU fast path was not doing the correct thing for input bitmaps of
differing sizes. This change brings the fast path in line with the
slow path: use the union of foreground and background bounds as bounds,
offset the draw context by the bounds translation, and translate the
foreground and background independently by their respective offsets.
Finally, we add a texture domain for the background fragment
processor, since we may access texels outside its domain.
Note: this adds two new test cases to the xfermodeimagefilter GM, so
those will need to be rebaselined.
BUG=568196
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1588633002
Review URL: https://codereview.chromium.org/1588633002
If the input bitmap passed to SkTileImageFilter does not fill the
srcRect, we were tiling this incorrectly (see the first sample
from tileimage filter -- it draws from a srcRect of 12,12 50x50
to a dstRect of 0,0 50x50. There should be no tiling at all
in this case!)
In order to fix this, we need to pad the bitmap out to srcRect,
and tile with that. In order to tile correctly in the GPU case,
we need to request a tileable texture.
NOTE: this will change the results of the tileimagefilter GM (correctness,
and added src / dest rects).
BUG=skia:4774
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1570133003
Review URL: https://codereview.chromium.org/1570133003
Epsilon bias to keep bitmap sample rounding consistent with geometry
rounding.
Also update the GM to draw an outer border + drop uninteresting
scales in favor of negative scale variants.
BUG=skia:4680,skia:4649
R=reed@google.com,caryclark@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/1527633002
In the current implementation, a blur filter is always created even in the
case when sigma.fX == 0 && sigma.fY == 0. This CL makes the blur filter
return input in this case.
BUG=568393
Review URL: https://codereview.chromium.org/1518643002
Make SkAutoTMalloc's interface look more like SkAutoMalloc:
- add free(), which does what you expect
- make reset() return a pointer fPtr
No public API changes (SkAutoTMalloc is in include/private)
BUG=skia:2148
Review URL: https://codereview.chromium.org/1516833003
Needed to enlarge radii to surface bugs without exceeding max texture size on low end devices.
BUG=chromium:477684
Review URL: https://codereview.chromium.org/1508003008
Because the convolution kernel is (currently) applied in device space,
there's no way to know which object-space pixels will be touched. So
return false from canComputeFastBounds().
The results from the matrixconvolution GM were actually wrong, since
they were showing edge differences on the clip boundaries, where they
should really only show on crop boundaries. I added a crop to the GM
to keep the results the same (which are useful to test the different
convolution tile modes).
While I was at it, SkImageFilter::affectsTransparentBlack() was
inapplicable on most things except color filters, and its use on
leaf nodes was confusing. So I removed it, and made
SkImageFilter::canComputeFastBounds() virtual instead.
BUG=skia:4630
Review URL: https://codereview.chromium.org/1500923004
Reason for revert:
Introduced memory leak; pixel changes in Chrome.
Original issue's description:
> Matrix convolution bounds fix; affectsTransparentBlack fixes.
>
> Because the convolution kernel is (currently) applied in device space,
> there's no way to know which object-space pixels will be touched. So
> return false from canComputeFastBounds().
>
> The results from the matrixconvolution GM were actually wrong, since
> they were showing edge differences on the clip boundaries, where they
> should really only show on crop boundaries. I added a crop to the GM
> to keep the results the same (which are useful to test the different
> convolution tile modes).
>
> While I was at it, SkImageFilter::affectsTransparentBlack() was
> inapplicable on most things except color filters, and its use on
> leaf nodes was confusing. So I removed it, and made
> SkImageFilter::canComputeFastBounds() virtual instead.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/8705ec80518ef551994b82ca5ccaeb0241d6adecTBR=reed@google.com,reed@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1497083005
Because the convolution kernel is (currently) applied in device space,
there's no way to know which object-space pixels will be touched. So
return false from canComputeFastBounds().
The results from the matrixconvolution GM were actually wrong, since
they were showing edge differences on the clip boundaries, where they
should really only show on crop boundaries. I added a crop to the GM
to keep the results the same (which are useful to test the different
convolution tile modes).
While I was at it, SkImageFilter::affectsTransparentBlack() was
inapplicable on most things except color filters, and its use on
leaf nodes was confusing. So I removed it, and made
SkImageFilter::canComputeFastBounds() virtual instead.
BUG=skia:
Review URL: https://codereview.chromium.org/1500923004
When the parallel stroke to the curve can't be computed from
the intersection of the tangent lines, as straight line connects
the two points instead. Allow the intersection to succeed unless
the ratio isn't finite or the contribution of (1 - ratio) isn't
significant.
R=reed@google.com,fmalita@chromium.org
BUG=skia:4603
Review URL: https://codereview.chromium.org/1484873003
If the client wants no caching, and we haven't already cached it, pass the
caller's dst-buffer directly down to the generator, avoiding the (previous)
extra memcpy.
BUG=skia:4594
Review URL: https://codereview.chromium.org/1473373002
This shouldn't really make any difference but allocating and holding on to a GrRenderTarget for each test target generates image differences for Mali GPUs. This CL allows an existing render target to be used for the test target.
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/1447113002
Makes it so that the oversized-texture/bmp case doesn't run on the CPU and makes it so that the subrect rendered is adjacent to the texture pad area on the bottom/right edges.
Review URL: https://codereview.chromium.org/1424473006
This allows internal Gr texture creation code to succeed for extraneous textures while running the bleed GM. This means we can turn on the shader variants.
Review URL: https://codereview.chromium.org/1418473004
An additional positive of this CL is that GrGLShaderBuilder is now GL independent besides GrGLProgramBuilder
BUG=skia:
Review URL: https://codereview.chromium.org/1431433003
Reason for revert:
re-land once layout test have been disabled (so they can be rebased)
Original issue's description:
> Update feSpotLight to match spec
>
> This change updates feSpotLight to match the spec via two changes:
>
> 1) specularExponent is ignored if the spotlight has no coneAngle (GPU
> bug only). This change updates the GPU path so that it matches the
> CPU path and the spec in this regard.
>
> 2) specularExponent is clamped to the 1-128 range. The spec does not
> specify a clamp for the specularExponent attribute of feSpotLight.
> Note that the spec *does* specify this clamp for the
> specularExponent attribute of feSpecularLighting. It looks like we
> incorrectly applied this to both specularExponent attributes.
>
> This change (along with a parallel change in Blink) allows us to pass
> the SVG filter effects conformance test here:
> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/filters-light-01-f.html
>
> Additionally, this brings our behavior in line with Safari and Edge’s
> behavior on this filter.
>
> Two new cases were added to gm/lighting.cpp to catch these issues:
> - The existing spotlight case exercised the path where our specular
> exponent was between 1-128 and had a limiting cone angle.
> - The first new spotlight case exercises the path where our specular
> exponent is between 1-128 and we do not have a limiting cone angle.
> - The second new spotlight case exercises the path where the specular
> exponent is not within the 1-128 range, to ensure that we don’t
> incorrectly clip to this range.
>
> BUG=472849
>
> Committed: https://skia.googlesource.com/skia/+/c84ccb070258db2803a9e8f532bfe7239a737063TBR=senorblanco@google.com,senorblanco@chromium.org,bsalomon@google.com,ericrk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=472849
Review URL: https://codereview.chromium.org/1417463006
This change updates feSpotLight to match the spec via two changes:
1) specularExponent is ignored if the spotlight has no coneAngle (GPU
bug only). This change updates the GPU path so that it matches the
CPU path and the spec in this regard.
2) specularExponent is clamped to the 1-128 range. The spec does not
specify a clamp for the specularExponent attribute of feSpotLight.
Note that the spec *does* specify this clamp for the
specularExponent attribute of feSpecularLighting. It looks like we
incorrectly applied this to both specularExponent attributes.
This change (along with a parallel change in Blink) allows us to pass
the SVG filter effects conformance test here:
http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/filters-light-01-f.html
Additionally, this brings our behavior in line with Safari and Edge’s
behavior on this filter.
Two new cases were added to gm/lighting.cpp to catch these issues:
- The existing spotlight case exercised the path where our specular
exponent was between 1-128 and had a limiting cone angle.
- The first new spotlight case exercises the path where our specular
exponent is between 1-128 and we do not have a limiting cone angle.
- The second new spotlight case exercises the path where the specular
exponent is not within the 1-128 range, to ensure that we don’t
incorrectly clip to this range.
BUG=472849
Review URL: https://codereview.chromium.org/1403403003
premultiplied colors, however the flag for whether or not to do this,
which is present in their parent filters, is dropped when creating the
GL implementations. This change adds logic to forward the value from
the parent filter to the GL implementation.
This makes GPU behavior match software and fixes a WebKit
LayoutTest. See referenced bug.
BUG=473186
Review URL: https://codereview.chromium.org/1410553002
The result is that the set of "generic" imagefilters (e.g. SkColorFilterImageFilter) that use drawing commands to return their results will now stay in the same domain as their src (i.e. gpu-src --> gpu-dst).
ApplyFilterGM exercises this, and now asserts this same-domain invariant.
BUG=skia:4467
Review URL: https://codereview.chromium.org/1401053003
This method is different from MatrixFilter, in that MatrixFilter does not require a pre-existing
filter, but LocalM does. Also change the comment to be more general, as there is no promise that
we return a different subclass, and certainly not a specific subclass.
This pattern of obj->newWithModifiers() also more closely matches the pattern in SkImage (newSubset).
BUG=skia:
Review URL: https://codereview.chromium.org/1402133002
At draw time, this filter simply concatenates the given matrix to the
CTM, and recurses on its input. The matrix is thus applied to any
upstream filter parameters and crop rects.
BUG=skia:
Review URL: https://codereview.chromium.org/1392833005
Result:
- clients can get a filtered version of an image without having to setup a temp drawing environment
- for some cases, the process is more efficient even than (deprecated) drawSprite, since there is no need to draw/copy the result
Impl:
- made Proxy virtual so we don't need to have an existing device to use it
This, in conjunction with LocalMatrixImageFilter, should allow us to simplify and optimize ApplyImageFilter() in cc/output/gl_renderer.cc
BUG=skia:
Review URL: https://codereview.chromium.org/1390913005
Migrating the flag to embedder defines (Chromium already guarded).
Also augment gradient-focused GMs to generate both dithered/undithered
results.
BUG=skia:4436
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1400813006
Reason for revert:
Breaks Chrome with this link error: ../../third_party/skia/include/effects/SkMorphologyImageFilter.h:75: error: undefined reference to 'SkMorphologyImageFilter::SkMorphologyImageFilter(int, int, SkImageFilter*, SkImageFilter::CropRect const*)'
../../third_party/skia/include/effects/SkMorphologyImageFilter.h:104: error: undefined reference to 'SkMorphologyImageFilter::SkMorphologyImageFilter(int, int, SkImageFilter*, SkImageFilter::CropRect const*)'
Presumably due to code in third_party/WebKit/Source/platform/graphics/filters/FEMorphology.cpp that contains:
#include "SkMorphologyImageFilter.h"
...
if (m_type == FEMORPHOLOGY_OPERATOR_DILATE)
return adoptRef(SkDilateImageFilter::Create(radiusX, radiusY, input.get(), &rect));
return adoptRef(SkErodeImageFilter::Create(radiusX, radiusY, input.get(), &rect));
Original issue's description:
> factories should return baseclass, allowing the impl to specialize
>
> waiting on https://codereview.chromium.org/1386163002/# to land
>
> BUG=skia:4424
>
> Committed: https://skia.googlesource.com/skia/+/80a6dcaa1b757826ed7414f64b035d512d9ccbf8TBR=senorblanco@google.com,robertphillips@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4424
Review URL: https://codereview.chromium.org/1389063002
The "zeroPath" and emptystroke GMs capture this issue.
This CL changes the following PDF GMs: emptystroke dashing4
lineclosepath dashing3 zeroPath linepath
complexclip3_complex complexclip3_simple roundrects
degeneratesegments filltypes strokerect pathfill
inverse_paths desk_chalkboard.skp
After this change, all PDF GMs look better (closer to 8888).
The dashing4, emptystroke, and zeroPath GMs still need a lot
of work to make them look right.
BUG=538726
Review URL: https://codereview.chromium.org/1374383004
drawImage calls now properly embeds the original jpeg.
NOTE: drawBitmap*() calls no longer embed JPEG files when
possible (this is in advance of eliminating bitmaps backed
by encoded data). Chromium has already moved from
drawBitmap to drawImage.
Comparisons:
control:
total PDF drawImage/drawBitmap calls: 8010
total PDF jpeg images: 0
total PDF regular images: 3581
experiament:
total PDF drawImage/drawBitmap calls: 8014
total PDF jpeg images: 271
total PDF regular images: 3311
total PDF regular images: 3582 (271 + 3311)
When comparing rendered output there were perceptual
differences in the following four GMs: colorcube, emboss,
colormatrix, and tablecolorfilter. All of these differences
were improvements (that is, closer to the 8888 rendering)
due fixing a bug with colorfilters and forgetting to call
notifyPixelsChanged.
No SKPs had perceptual differences.
Total PDF size dropped from 133964 kB to 126276 kB, a 5.7%
improvement (mostly due to restoring use of JPG images in
SKPs).
BUG=skia:4370
Review URL: https://codereview.chromium.org/1372783003
An alternative way of addressing this is to alter SkCanvas::drawRoundRect to just reject isEmpty (i.e., un-sorted or truly empty) input rects.
BUG=skia:3786
Review URL: https://codereview.chromium.org/1373293002
One side effect is that the SkShader's (or implicit shader's) fragment processor is responsible for the transition from an unpremul paint color to a premul color.
Review URL: https://codereview.chromium.org/1348583002
To avoid breaking existing SKPs, add a deserialization stub which
unflattens SkBitmapSource records to SkImageSources.
R=reed@google.com,mtklein@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1363913002
Previously annotations added between saveLayer/restore were lost.
Merge annotations in SkPDFDevice::drawDevice(). Also modified code to
apply correct transformation and clipping on annotations added between
saveLayer/restore:
- Apply the initial transform only when adding the annotations into the
doc, otherwise we need to unapply sub-device's initial transform
before merging the annotations into parent-device.
- Apply only device-local clipping. fClipStack is in global coordinates,
which is not suitable to clip rects in sub-devices.
BUG=skia:4080
BUG=503515
Review URL: https://codereview.chromium.org/1257533004
This makes the blurcircles bench go from ~33us to ~8us on Windows desktop.
It will require layout test suppressions
Review URL: https://codereview.chromium.org/1311583005
Blink is migrating away from SkBitmaps, so we need an SkImage-based
SkImageFilter source. This is pretty much a 1-1 equivalent of
SkBitmapSource.
To avoid duplication, relocate the SkImage deserialization logic
from SkPictureData to SkReadBuffer.
R=reed@google.com,robertphillips@google.com,senorblanco@chromium.org
Review URL: https://codereview.chromium.org/1343703005
