To do this, create SkImageCacherator, which wraps a generator and provides an
interface to get a cached answer for either the raster or texture output of
the generator.
BUG=skia:
Review URL: https://codereview.chromium.org/1291803002
Additionally this CL:
forces the light colors to be opaque
forces the light direction to be normalized
adds a raster implementation
adds a gm
Review URL: https://codereview.chromium.org/1245883003
Ganesh was not expanding the quad colors to vertex colors before calling drawVertices.
The new GM would've caught this bug and reveals Ganesh's limitations re the various xfer modes used with drawAtlas (i.e., w/o AA Ganesh only supports kModulate, w/ AA Ganesh only supports the coefficient-based xfer modes).
Review URL: https://codereview.chromium.org/1254943002
This change is motivated by a recent switch in how chromium handles
<video> color spaces, making rec709 more commonly used. This will
allow video -> canvas copies to take the fast GPU path when we're using
709, just as we do with 601 and jpeg.
Chromium-side change: https://codereview.chromium.org/1236313002
Review URL: https://codereview.chromium.org/1241723005
The gm output on different font platforms is so different
that comparing images in Gold has little value. Separate the
images by appending platform information to the gm name to
group somewhat similar images together.
Note that this does not attempt to make sure that all images
generated by Gold are nearly pixel identical; it only reduces
the number of nonsensical comparisons.
R=bungeman@google.com
Review URL: https://codereview.chromium.org/1245643002
The new test is disabled by default, as it's quite slow.
We can run it if we suspect problems by passing -x to DM.
This test would have been failing before the bug fix, and now is passing.
Assuming the Priv on the end means it's not considered public API...
TBR=reed@google.com
BUG=skia:4052
Review URL: https://codereview.chromium.org/1228333003
Convert the Mac-specific font text statically into
paths so that they draw the same on all platforms.
Add drawing portable text using the fake bold paint
setting so that the code path is tested everywhere
and but draws the same thing.
R=reed@google.com
Review URL: https://codereview.chromium.org/1234463006
Put font glyph data in test as path
instead of getting data from the Mac
font. THe font may change, and is
not available on most platforms.
Also remove unreachable code.
R=reed@google.com
Review URL: https://codereview.chromium.org/1230703005
The multicolored font that funster enables
only draws and measures on some platforms.
Removing it from the dcshader gm allows
the layout to be uniform on all devices,
making it easier to compare the output
in gold.
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/1231853004
(and a couple presubmit fixes)
This allows us to turn back on -Werror for LLVM coverage builds,
and more generally supports building with Clang 3.7.
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1232463006
this also exposes nine-patch drawing directly to devices, and creates a shared iterator for unrolling a nine-patch into single rect->rect draws.
BUG=skia:
Review URL: https://codereview.chromium.org/1211583003
Start moving to a world where everyone provides surface properties.
Most notably this exposes a portion of SkSurfaceProps to the C API.
BUG=skia:3934
Review URL: https://codereview.chromium.org/1195003003
This CL starts the process of pushing kLegacyFontHost_InitType-type SkSurfaceProps up the call stack and out of Skia. It:
Gets rid of the default SkBaseDevice ctor. This means everyone has to always hand an explicit SkSurfaceProps to it.
It makes public the SkBitmapDevice creation methods that require SkSurfaceProps.
Removes (in Skia's code base) all SkBitmapDevice ctor calls w/o SkSurfaceProps.
Makes the "recording" canvases (e.g., pdf, svg, xps) explicitly not use kLegacyFontHost_InitType.
Replicates the creating canvas/device's flags on saveLayer devices
BUG=skia:3934
Review URL: https://codereview.chromium.org/1204433002
Reason for revert:
breaks many bots with refcnt error
Original issue's description:
> make gm background colors 565 compatible
>
> Change a batch of GM tests to convert their background color
> so that it is representable in 8888 and 565.
>
> Enable portable text in those same tests to minimize platform
> differences.
>
> In a couple of bitmap tests, use portable typefaces instead of
> choosing 'Times' which may or may not be available on the platform.
>
> R=borenet@google.com
>
> Committed: https://skia.googlesource.com/skia/+/be7f768a357aefb39c42d24b81b24d647bb6ab70TBR=borenet@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1184123002
Change a batch of GM tests to convert their background color
so that it is representable in 8888 and 565.
Enable portable text in those same tests to minimize platform
differences.
In a couple of bitmap tests, use portable typefaces instead of
choosing 'Times' which may or may not be available on the platform.
R=borenet@google.com
Review URL: https://codereview.chromium.org/1176243006
- input param to addFoo (e.g. addRect), where only CW or CCW are valid)
- output param from computing functions, that sometimes return kUnknown
This CL's intent is to split these into distinct enums/features:
- Direction (public) loses kUnknown, and is only used for input
- FirstDirection (private) is used for computing the first direction we see when analyzing a contour
BUG=skia:
Review URL: https://codereview.chromium.org/1176953002
This experiment replaces the label used in the aaxfermodes gm with
aliased text generated from paths common to all platforms.
Since there is no way today to generate all dm output from trybots,
this will be checked in to confirm that this strategy provides simpler
output across devices.
This does not introduce a new public interface; instead, dm uses
a extern backdoor to install the SkTypeface::CreateFromName
handler.
Review URL: https://codereview.chromium.org/1163283002
Reason for revert:
Blink
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
>
> Committed: https://skia.googlesource.com/skia/+/0be685755f942baea26c66a87226b569fc17e960TBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1156583004
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
Review URL: https://codereview.chromium.org/1152553006
Reason for revert:
breaking tests
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4eTBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1143083006
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Review URL: https://codereview.chromium.org/1152553006
Removes the runtime logic used by PorterDuffXferProcessor to decide
blend coeffs and shader outputs, and instead uses a compile-time
constant table of pre-selected blend formulas. Separates out the dst
read fallback into its own XP.
Introduces a new blend strategy for srcCoeff=0 that can apply coverage
with a reverse subtract blend equation instead of dual source
blending.
Adds new macros in GrBlend.h to analyze blend formulas both runtime.
Removes kSetCoverageDrawing_OptFlag and GrSimplifyBlend as they are no
longer used.
Adds a GM that verifies all xfermodes, including arithmetic, with the
color/coverage invariants used by Porter Duff.
Adds a unit test that verifies each Porter Duff formula with every
color/coverage invariant.
Major changes:
* Uses a reverse subtract blend equation for coverage when srcCoeff=0
(clear, dst-out [Sa=1], dst-in, modulate). Platforms that don't
support dual source blending no longer require a dst copy for
dst-in and modulate.
* Sets BlendInfo::fWriteColor to false when the blend does not modify
the dst. GrGLGpu will now use glColorMask instead of blending for
these modes (dst, dst-in [Sa=1], modulate ignored for [Sc=1]).
* Converts all SA blend coeffs to One for opaque inputs, and ISA to
Zero if there is also no coverage. (We keep ISA around when there
is coverage because we use it to tweak alpha for coverage.)
* Abandons solid white optimizations for the sake of simplicity
(screen was the only mode that previous had solid white opts).
Minor differences:
* Inconsequential differences in opt flags (e.g. we now return
kCanTweakAlphaForCoverage_OptFlag even when there is no coverage).
* Src coeffs when the shader outputs 0.
* IS2C vs IS2A when the secondary output is scalar.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/9a70920db22b6309c671f8e5d519bb95570e4414
Review URL: https://codereview.chromium.org/1124373002
This patch addresses two issues:
1) Textblobs with abandoned strikes were not properly regenerating.
2) Provided by ericrk - GrTextBlobCache removed blobs from |fCache| during freeAll, but left
potentially released blobs in the |fBlobList|. We now remove these from
|fBlobList| as well.
BUG=skia:
Review URL: https://codereview.chromium.org/1160633002
This is mainly a mechanical CL. There were some fiddly bits in GrContext.cpp where it no longer had access to the GrDrawTarget (and had to use the new GrDrawContext).
I've converted GrAARectRenderer & GrOvalRenderer into static classes so I could stop allocating them.
Review URL: https://codereview.chromium.org/1151283004
Reason for revert:
Blocking DEPS roll into Chromium. Crashing virtual/gpu/fast/canvas/canvas-composite-*.html tests with the assert
../../third_party/skia/src/gpu/gl/builders/GrGLFragmentShaderBuilder.cpp:281: failed assertion "k110_GrGLSLGeneration != gpu->glslGeneration() || fOutputs.empty()"
Original issue's description:
> Implement Porter Duff XP with a blend table
>
> Removes the runtime logic used by PorterDuffXferProcessor to decide
> blend coeffs and shader outputs, and instead uses a compile-time
> constant table of pre-selected blend formulas.
>
> Introduces a new blend strategy for srcCoeff=0 that can apply coverage
> with a reverse subtract blend equation instead of dual source
> blending.
>
> Adds new macros in GrBlend.h to analyze blend formulas both runtime.
>
> Removes kSetCoverageDrawing_OptFlag and GrSimplifyBlend as they are no
> longer used.
>
> Adds a GM that verifies all xfermodes, including arithmetic, with the
> color/coverage invariants used by Porter Duff.
>
> Adds a unit test that verifies each Porter Duff formula with every
> color/coverage invariant.
>
> Major changes:
>
> * Uses a reverse subtract blend equation for coverage when srcCoeff=0
> (clear, dst-out [Sa=1], dst-in, modulate). Platforms that don't
> support dual source blending no longer require a dst copy for
> dst-in and modulate.
>
> * Sets BlendInfo::fWriteColor to false when the blend does not modify
> the dst. GrGLGpu will now use glColorMask instead of blending for
> these modes (dst, dst-in [Sa=1], modulate ignored for [Sc=1]).
>
> * Converts all SA blend coeffs to One for opaque inputs, and ISA to
> Zero if there is also no coverage. (We keep ISA around when there
> is coverage because we use it to tweak alpha for coverage.)
>
> * Abandons solid white optimizations for the sake of simplicity
> (screen was the only mode that previous had solid white opts).
>
> Minor differences:
>
> * Inconsequential differences in opt flags (e.g. we now return
> kCanTweakAlphaForCoverage_OptFlag even when there is no coverage).
>
> * Src coeffs when the shader outputs 0.
>
> * IS2C vs IS2A when the secondary output is scalar.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9a70920db22b6309c671f8e5d519bb95570e4414TBR=egdaniel@google.com,bsalomon@google.com,cdalton@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1153993002
Removes the runtime logic used by PorterDuffXferProcessor to decide
blend coeffs and shader outputs, and instead uses a compile-time
constant table of pre-selected blend formulas.
Introduces a new blend strategy for srcCoeff=0 that can apply coverage
with a reverse subtract blend equation instead of dual source
blending.
Adds new macros in GrBlend.h to analyze blend formulas both runtime.
Removes kSetCoverageDrawing_OptFlag and GrSimplifyBlend as they are no
longer used.
Adds a GM that verifies all xfermodes, including arithmetic, with the
color/coverage invariants used by Porter Duff.
Adds a unit test that verifies each Porter Duff formula with every
color/coverage invariant.
Major changes:
* Uses a reverse subtract blend equation for coverage when srcCoeff=0
(clear, dst-out [Sa=1], dst-in, modulate). Platforms that don't
support dual source blending no longer require a dst copy for
dst-in and modulate.
* Sets BlendInfo::fWriteColor to false when the blend does not modify
the dst. GrGLGpu will now use glColorMask instead of blending for
these modes (dst, dst-in [Sa=1], modulate ignored for [Sc=1]).
* Converts all SA blend coeffs to One for opaque inputs, and ISA to
Zero if there is also no coverage. (We keep ISA around when there
is coverage because we use it to tweak alpha for coverage.)
* Abandons solid white optimizations for the sake of simplicity
(screen was the only mode that previous had solid white opts).
Minor differences:
* Inconsequential differences in opt flags (e.g. we now return
kCanTweakAlphaForCoverage_OptFlag even when there is no coverage).
* Src coeffs when the shader outputs 0.
* IS2C vs IS2A when the secondary output is scalar.
BUG=skia:
Review URL: https://codereview.chromium.org/1124373002
Constructing the gm tests and benches causes many calls to font loads.
This is visible as profiling samples in fontconfig and freetype on Linux
for all profiling runs of nanobench. This complicates analysis of
test-cases that are suspected of being slow due to font-related issues.
Move the font loading to GM::onOnceBeforeDraw and Benchmark::onPreDraw.
This way the code is not executed if the testcase does not match the
nanobench --match filter. This way the samples in font-related code are
more easy to identify as legitimate occurances caused by the testcase.
This should not cause differences in timings, because:
* Benchmark::preDraw / onPreDraw is defined to be run outside the timer
* GM::runAsBench is not enabled for any of the modified testcases. Also
nanobench untimed warmup round should run the onOnceBeforeDraw.
(and there are other GM::runAsBench gms already doing loading in
onOnceBeforeDraw).
Changes the behavior:
In TextBench:
Before, the test would report two different gms with the same name if
the color emoji font was not loaded successfully.
After, the test always reports all tests as individual names.
Generally:
The errors from loading fonts now print inbetween each testcase, as
opposed to printing during construction phase. Sample output:
( 143/145 MB 1872) 14.7ms 8888 gm quadclosepathResource /fonts/Funkster.ttf not a valid font.
( 160/160 MB 1831) 575µs 8888 gm surfacenewResource /fonts/Funkster.ttf not a valid font.
( 163/165 MB 1816) 12.5ms 8888 gm linepathResource /fonts/Funkster.ttf not a valid font.
( 263/411 MB 1493) 118ms 8888 gm typefacestyles_kerningResource /fonts/Funkster.ttf not a valid font.
( 374/411 MB 1231) 7.16ms 565 gm getpostextpathResource /fonts/Funkster.ttf not a valid font.
( 323/411 MB 1179) 4.92ms 565 gm stringartResource /fonts/Funkster.ttf not a valid font.
( 347/493 MB 917) 191ms 565 gm patch_gridResource /fonts/Funkster.ttf not a valid font.
( 375/493 MB 857) 23.9ms gpu gm clipdrawdrawCannot render path (0)
( 393/493 MB 706) 2.91ms unit test ParsePath------ png error IEND: CRC error
( 394/493 MB 584) 166ms gpu gm hairmodesResource /fonts/Funkster.ttf not a valid font.
Resource /fonts/Funkster.ttf not a valid font.
Resource /fonts/Funkster.ttf not a valid font.
...
Review URL: https://codereview.chromium.org/1144023002
A stroked conic computes the outset quad's control point by
computing the intersection of the quad's endpoints. If the
the denominator used to compute the scale factor for the
control point is small, check to see if the numerator is also
small so that the division stays bounded.
Also clean up error returns and internal function calls to
simplify the code.
Additionally, remove comic max curvature (unimplemented) and call
extrema functions instead to handle cases where the conic is degenerate
or is a line.
R=reed@google.com, fmalita@chromium.org
BUG=skia:3843
Review URL: https://codereview.chromium.org/1144883003
What is going on here is that, after the mapPoints in fillAANestedRects, devInside was upside down so the isEmpty check was always firing. I don't see why we need to avoid having devInside sorted.
BUG=488103
Review URL: https://codereview.chromium.org/1135753004
Reason for revert:
Appears to be breaking Linux ARM bots:
FAILED:
/usr/local/google/home/mosaic-role/slave/repo_clients/chromium_tot/chromium/src/../../prebuilt/toolchain/armv7a/bin/armv7a-cros-linux-gnueabi-g++
... -o obj/third_party/skia/src/ports/skia_library.SkFontHost_FreeType.o
../../third_party/skia/src/ports/SkFontHost_FreeType.cpp:37:31: fatal error:
freetype/ftmm.h: No such file or directory
#include FT_MULTIPLE_MASTERS_H
^
compilation terminated.
Original issue's description:
> Font variations.
>
> Multiple Master and TrueType fonts support variation axes.
> This implements back-end support for axes on platforms which
> support it.
>
> Committed: https://skia.googlesource.com/skia/+/05773ed30920c0214d1433c07cf6360a05476c97
>
> Committed: https://skia.googlesource.com/skia/+/3489ee0f4fa34f124f9de090d12bdc2107d52aa9TBR=reed@google.com,mtklein@google.com,djsollen@google.com,halcanary@google.com,bungeman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1139123008
Multiple Master and TrueType fonts support variation axes.
This implements back-end support for axes on platforms which
support it.
Review URL: https://codereview.chromium.org/1027373002
This CL refactors the location of the GrBufferAllocPools so they reside entirely inside the GrBatchTarget. This is in preparation for making them use scratch resources.
Review URL: https://codereview.chromium.org/1131553002
The last user of the GDI default font in DW is
onMatchFamilyStyleCharacter and it doesn't appear to actually need
to use it. This change removes a system call, making things a bit
faster, as well as eliminating a call blocked in the sandbox.
BUG=chromium:459056
Review URL: https://codereview.chromium.org/1107283003
Effectively all this does is future-proof any GLSL-specific code, as
GLSLCaps is just a typedef of GLCaps.
BUG=skia:
Review URL: https://codereview.chromium.org/1109863004
patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs
On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.8-Clang-Arm7-Debug-Android-Trybot,Build-Ubuntu-GCC-Arm7-Release-Android_NoNeon-Trybot
Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ec
Review URL: https://codereview.chromium.org/1109643002
Reason for revert:
compile failures.
Original issue's description:
> Mike's radial gradient CL with better float -> int.
>
> patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
>
> This looks quite launchable. radial_gradient3, min of 100 samples:
> N5: 985µs -> 946µs
> MBP: 395µs -> 279µs
>
> On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
>
> BUG=skia:
>
> CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ecTBR=reed@google.com,robertphillips@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1109883003
patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs
On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot
Review URL: https://codereview.chromium.org/1109643002
We only embed images with YUV planes. That should only grab the
subset of color JPEGs supported by PDF.
BUG=skia:3180
Review URL: https://codereview.chromium.org/1025773002
High quality anisotropic is an interesting edge case for the gpu backend. For scales that are both minimizing and maximizing Ganesh falls back to MipMaps which can turn out too blurry.
BUG=472864
Review URL: https://codereview.chromium.org/1058133003
This CL also adds a new parameter to SkBitmapSource which gives the user control of the filter quality.
BUG=472795
Review URL: https://codereview.chromium.org/1072603002
For some reason, GM's are now being composited against white
in some modes, where the alpha used to be ignored (or composited
against black, I'm not sure which). At any rate, it doesn't
make much sense to have alpha in the result anyway, so let's clear to
opaque black instead of transparent black and avoid the problem.
This is a trial balloon for bitmapsource and pictureimagefilter.
If all goes well, I'll make this change more widely.
R=scroggo
BUG=skia:3319
Review URL: https://codereview.chromium.org/1074513002
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter, SkMatrixConvolutionImageFilter,
SkMatrixImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
For the SkMatrixConvolutionImageFilter, it seems the
GLSL clamp() function occasionally returns values outside
the clamped range, resulting in access of garbage
texels even in GL_NEAREST. The fix here is to clamp to a
rect inset by half a texel. There was also a bug in
the unpremultiply step when fConvolveAlpha is false.
For SkMatrixImageFilter, the fix was to make the generic
draw path be more careful about when to use texture domain.
If the bitmap already has a texture, use texture domain
if the srcRect is smaller than the entire texture (not
the entire bitmap).
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c
Review URL: https://codereview.chromium.org/1034733002
Reason for revert:
Spoke to Stephen about this. Reverting because failing debug builds:
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Mac10.9-Clang-MacMini6.2-GPU-HD4000-x86_64-Debug/builds/51https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/54
Original issue's description:
> Implement approx-match support in image filter saveLayer() offscreen.
>
> Currently, the GPU-side image filter implementation creates
> exact-match textures for the offscreen backing stores for
> saveLayer(). This is because several filters have GPU
> implementations which depend on the texture coordinates
> being 0..1.
>
> The fix is three-fold:
>
> 1) Store the actual requested size in the SkGpuDevice, so
> that when wrapping it in an SkBitmap for passing to
> filterImage(), we can give it the original size.
> 2) Fix the filters (SkMagnifierImageFilter,
> SkLightingImageFilter, SkMatrixConvolutionImageFilter,
> SkMatrixImageFilter) whose GPU implementation depends on
> 0..1 texture coordinates.
> 3) Remove the exception for GPU-side image filters in
> SkCanvas::internalSaveLayer().
>
> For the lighting filters, there were two bugs which were
> cancelling each other out: the sobel filter matrix was
> being computed upside down, but then we'd negate the
> resulting normal. This worked fine in the exact-match case,
> but in the approx-match case we'd sample garbage along
> the edge pixels. Also, we never implemented the edge pixels
> according to spec in the GPU case. It requires a
> different fragment shader for each edge of the nine-patch,
> which meant we couldn't use asFragmentProcessor(), and had
> to implement the drawing via a filterImageGPU() override.
> In order to avoid polluting the public API, I inserted a
> new base class, SkLightingImageFilterInternal above
> Sk[Diffuse|Specular]LightingImageFilter to handle the
> implementation.
>
> For the SkMatrixConvolutionImageFilter, it seems the
> GLSL clamp() function occasionally returns values outside
> the clamped range, resulting in access of garbage
> texels even in GL_NEAREST. The fix here is to clamp to a
> rect inset by half a texel. There was also a bug in
> the unpremultiply step when fConvolveAlpha is false.
>
> For SkMatrixImageFilter, the fix was to make the generic
> draw path be more careful about when to use texture domain.
> If the bitmap already has a texture, use texture domain
> if the srcRect is smaller than the entire texture (not
> the entire bitmap).
>
> N.B.: this change will cause some minor pixel diffs in the
> GPU results of the following GMs (and possibly more):
> matriximagefilter, matrixconvolution, imagefiltersscaled,
> lighting, imagemagnifier, filterfastbounds,
> complexclip_aa_Layer_invert, complexclip_aa_layer,
> complexclip_bw_layer_invert, complexclip_bw_layer.
>
> BUG=skia:3532
>
> Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
>
> Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
>
> Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460cTBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057693002
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter, SkMatrixConvolutionImageFilter,
SkMatrixImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
For the SkMatrixConvolutionImageFilter, it seems the
GLSL clamp() function occasionally returns values outside
the clamped range, resulting in access of garbage
texels even in GL_NEAREST. The fix here is to clamp to a
rect inset by half a texel. There was also a bug in
the unpremultiply step when fConvolveAlpha is false.
For SkMatrixImageFilter, the fix was to make the generic
draw path be more careful about when to use texture domain.
If the bitmap already has a texture, use texture domain
if the srcRect is smaller than the entire texture (not
the entire bitmap).
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
Review URL: https://codereview.chromium.org/1034733002
Reason for revert:
Looks like this change is causing layout test failures which is blocking Skia's DEPS roll into Chromium:
https://codereview.chromium.org/1050563002/https://codereview.chromium.org/1043133005/https://codereview.chromium.org/1048273002/
Reverting to see if this fixes the DEPS roll.
Original issue's description:
> Implement approx-match support in image filter saveLayer() offscreen.
>
> Currently, the GPU-side image filter implementation creates
> exact-match textures for the offscreen backing stores for
> saveLayer(). This is because several filters have GPU
> implementations which depend on the texture coordinates
> being 0..1.
>
> The fix is three-fold:
>
> 1) Store the actual requested size in the SkGpuDevice, so
> that when wrapping it in an SkBitmap for passing to
> filterImage(), we can give it the original size.
> 2) Fix the filters (SkMagnifierImageFilter,
> SkLightingImageFilter) whose GPU implementation depends on
> 0..1 texture coordinates.
> 3) Remove the exception for GPU-side image filters in
> SkCanvas::internalSaveLayer().
>
> For the lighting filters, there were two bugs which were
> cancelling each other out: the sobel filter matrix was
> being computed upside down, but then we'd negate the
> resulting normal. This worked fine in the exact-match case,
> but in the approx-match case we'd sample garbage along
> the edge pixels. Also, we never implemented the edge pixels
> according to spec in the GPU case. It requires a
> different fragment shader for each edge of the nine-patch,
> which meant we couldn't use asFragmentProcessor(), and had
> to implement the drawing via a filterImageGPU() override.
> In order to avoid polluting the public API, I inserted a
> new base class, SkLightingImageFilterInternal above
> Sk[Diffuse|Specular]LightingImageFilter to handle the
> implementation.
>
> N.B.: this change will cause some minor pixel diffs in the
> GPU results of the following GMs (and possibly more):
> matriximagefilter, matrixconvolution, imagefiltersscaled,
> lighting, imagemagnifier, filterfastbounds,
> complexclip_aa_Layer_invert, complexclip_aa_layer,
> complexclip_bw_layer_invert, complexclip_bw_layer.
>
> BUG=skia:3532
>
> Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
>
> Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641TBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057443003
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Review URL: https://codereview.chromium.org/1034733002
Replace the implicit curve intersection with a geometric curve intersection. The implicit intersection proved mathematically unstable and took a long time to zero in on an answer.
Use pointers instead of indices to refer to parts of curves. Indices required awkward renumbering.
Unify t and point values so that small intervals can be eliminated in one pass.
Break cubics up front to eliminate loops and cusps.
Make the Simplify and Op code more regular and eliminate arbitrary differences.
Add a builder that takes an array of paths and operators.
Delete unused code.
BUG=skia:3588
R=reed@google.com
Review URL: https://codereview.chromium.org/1037573004
Reason for revert:
static void draw(SkCanvas* canvas,
const SkPaint& p,
const SkBitmap& src,
SkColorType colorType,
const char text[]) {
SkASSERT(src.colorType() == colorType);
canvas->drawBitmap(src, 0.0f, 0.0f);
canvas->drawText(text, strlen(text), 0.0f, 12.0f, p);
}
This assert is firing, at least on macs, where all images get decoded into 32bit at the moment.
Original issue's description:
> PDF: remove last use of SkPDFImage
>
> Add a GM.
>
> BUG=skia:255
>
> Committed: https://skia.googlesource.com/skia/+/86ad8d643624a55b02e529100bbe4e2940115fa1TBR=mtklein@google.com,halcanary@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:255
Review URL: https://codereview.chromium.org/1024113002
(This is essentially a revert of https://codereview.chromium.org/503833002/.)
This was necessary back when SkPaint was flattened even for in-process use. Now that we only flatten SkPaint for cross-process use, there's no need to serialize UniqueIDs.
Note: SkDropShadowImageFilter is being constructed with a croprect and UniqueID (of 0) in Blink. I've made the uniqueID param default to 0 temporarily, until this rolls in and Blink can be changed. (Blink can't be changed first, since unlike the other filters, there's no constructor that takes a cropRect but not a uniqueID.)
BUG=skia:
Review URL: https://codereview.chromium.org/1019493002
Need to check for zero-length gradients when using the new correction.
Make sure we use the old text sizes for color emoji test in dftext GM.
BUG=skia:3540
Review URL: https://codereview.chromium.org/1009973004
The core of the problem is that the system is asked to lookup the metrics for a character with id == 0. This causes a hit in the fCharToGlyphHash matching the sentinel glyph. This happens because fCharToGlpyhHash is initialized with all zeros, therefore, the fID is zero matching the char with id == 0. The fAdvanceX field of the sentinel glyph is in fact not initialized.
The bigger question is now did a zero character get passed to getUnicharMetrics?
The breaking code is basically as follows:
wchar_t glyph = L'S';
paint.measureText(&glyph, 2);
This get mischaracterized as a utf8 string instead of a utf16(?) string. Because of the little endian ordering, this is the character string 'L' '\0'. Since the size of the original string is two bytes (but a single character) the '\0' is treated as its own character and past to getUnicharMetrics.
TEST:
On windows failed using DrMemory. With this change does not fail.
BUG=463204
Review URL: https://codereview.chromium.org/977063002
This path renderer converts paths to linear contours, resolves intersections via Bentley-Ottman, implements a trapezoidal decomposition a la Fournier and Montuno to produce triangles, and renders those with a single draw call. It does not currently do antialiasing, so it must be used in conjunction with multisampling.
A fair amount of the code is to handle floating point edge cases in intersections. Rather than perform exact computations (which would require arbitrary precision arithmetic), we reconnect the mesh to reflect the intersection points. For example, intersections can occur above the current vertex, and force edges to be merged into the current vertex, requiring a restart of the intersections. Splitting edges for intersections can also force them to merge with formerly-distinct edges in the same polygon, or to violate the ordering of the active edge list, or the active edge state of split edges.
BUG=skia:
Review URL: https://codereview.chromium.org/855513004
Fix path bugs exposed by the path fuzzer.
Changes to existing gm and samplecode files defer their calls to construct
SkPath objects until the first draw instead of at test initialization.
Add an experimental call to SkPath to validate the internal SkPathRef.
Fix SkPath::addPoly to set the last moveto after adding a close verb.
Fix stroke to handle failures when computing the unit normal.
Add a unit test for the unit normal failure.
R=reed@google.com
Review URL: https://codereview.chromium.org/953383002
The looper can generate more than one quad, but if any one is degenerate,
give up, but not before generating the state for the line join to
produce the correct end.
Before, the early return allowed the inside path to contain multiple
movetos that caused reversePath to assert.
R=reed@google.com
Review URL: https://codereview.chromium.org/948043002
The strokes3 test was limted to 400x800. Allow the captured gm to
go to 1500x1500, and shift it down slightly so it isn't clipped.
Review URL: https://codereview.chromium.org/945363004
Also: Add SkDeflateWStream and associated unit tests.
SkPDFBitmap is a replacement for SkPDFImage. As of now, it only
supports 8888 bitmaps (the most common case).
SkPDFBitmap takes very little extra memory (aside from refing the
bitmap's pixels), and its emitObject() does not cache any data.
The SkPDFBitmap::Create function will check the canon for duplicates.
This can reduce the size of the output PDF.
Motivation: this gives another ~40% decrease in PDF memory overhead
TODO: Support other ColorTypes and scrap SkPDFImage.
BUG=skia:3030
Review URL: https://codereview.chromium.org/918813002
Add RotateCircles3 back as better-named QuadStroker.
Switch pathfill test to call skia before draw instead of in
initializer to avoid triggering debugging breakpoints.
Review URL: https://codereview.chromium.org/912273003
There was a scaling mistake visible in some JPEG images because the ratio between Y, U and V planes were assumed to be the same ratios as the ratio between texture sizes, which was wrong because texture have a minimum size of 16 and are rounded up to the next POT. Since the ratios between Y and UV planes are generally 1, 2 or 4, rounding up to the next POT would generally preserve this ratio, so that this bug was not very visible, apart from very small jpeg images of 8 or less pixels in either width or height.
BUG=457954
Committed: https://skia.googlesource.com/skia/+/e6eddf7dd85add7da41f22f2643bdd573ad1f1cf
Review URL: https://codereview.chromium.org/922273002
Reason for revert:
Turning Windows compile bots red.
Original issue's description:
> YUV scale fix
>
> There was a scaling mistake visible in some JPEG images because the ratio between Y, U and V planes were assumed to be the same ratios as the ratio between texture sizes, which was wrong because texture have a minimum size of 16 and are rounded up to the next POT. Since the ratios between Y and UV planes are generally 1, 2 or 4, rounding up to the next POT would generally preserve this ratio, so that this bug was not very visible, apart from very small jpeg images of 8 or less pixels in either width or height.
>
> BUG=457954
>
> Committed: https://skia.googlesource.com/skia/+/e6eddf7dd85add7da41f22f2643bdd573ad1f1cfTBR=bsalomon@google.com,sugoi@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=457954
Review URL: https://codereview.chromium.org/926123002
There was a scaling mistake visible in some JPEG images because the ratio between Y, U and V planes were assumed to be the same ratios as the ratio between texture sizes, which was wrong because texture have a minimum size of 16 and are rounded up to the next POT. Since the ratios between Y and UV planes are generally 1, 2 or 4, rounding up to the next POT would generally preserve this ratio, so that this bug was not very visible, apart from very small jpeg images of 8 or less pixels in either width or height.
BUG=457954
Review URL: https://codereview.chromium.org/922273002
BUG=skia:1366
For the added bench, the collapsing makes the bench take:
- 70% of the time for CPU rendering of 3 consecutive matrix filters
- almost no change in the GPU rendering of the matrix filters
- 50% of the time for CPU and GPU rendering of 3 consecutive table filters
Review URL: https://codereview.chromium.org/776673002
Fold alpha to the inner savelayer in savelayer-savelayer-restore
patterns such as this:
SaveLayer (non-opaque)
Save
ClipRect
SaveLayer
Restore
Restore
Restore
Current blink generates these for example for SVG content such as this:
<path style="opacity:0.5 filter:url(#blur_filter)"/>
The outer save layer is due to the opacity and the inner one is due to
blur filter being implemented with picture image filter.
Reduces layers in desk_carsvg.skp testcase from 115 to 78.
BUG=skia:3119
Review URL: https://codereview.chromium.org/835973005
SkStream is a stateful object, so it does not make sense for it to have
multiple owners. Make SkStream inherit directly from SkNoncopyable.
Update methods which previously called SkStream::ref() (e.g.
SkImageDecoder::buildTileIndex() and SkFrontBufferedStream::Create(),
which required the existing owners to call SkStream::unref()) to take
ownership of their SkStream parameters and delete when done (including
on failure).
Switch all SkAutoTUnref<SkStream>s to SkAutoTDelete<SkStream>s. In some
cases this means heap allocating streams that were previously stack
allocated.
Respect ownership rules of SkTypeface::CreateFromStream() and
SkImageDecoder::buildTileIndex().
Update the comments for exceptional methods which do not affect the
ownership of their SkStream parameters (e.g.
SkPicture::CreateFromStream() and SkTypeface::Deserialize()) to be
explicit about ownership.
Remove test_stream_life, which tested that buildTileIndex() behaved
correctly when SkStream was a ref counted object. The test does not
make sense now that it is not.
In SkPDFStream, remove the SkMemoryStream member. Instead of using it,
create a new SkMemoryStream to pass to fDataStream (which is now an
SkAutoTDelete).
Make other pdf rasterizers behave like SkPDFDocumentToBitmap.
SkPDFDocumentToBitmap delete the SkStream, so do the same in the
following pdf rasterizers:
SkPopplerRasterizePDF
SkNativeRasterizePDF
SkNoRasterizePDF
Requires a change to Android, which currently treats SkStreams as ref
counted objects.
Review URL: https://codereview.chromium.org/849103004
Restructure SkGpuDevice creation:
*SkSurfaceProps are optional.
*Use SkSurfaceProps to communicate DF text rather than a flag.
*Tell SkGpuDevice::Create whether RT comes from cache or not.
Review URL: https://codereview.chromium.org/848903004
Reason for revert:
This CL introduces rendering conflicts with hairlines (i.e., the hairlines get overwritten). These conflicts are particularly visible on the following GMs (for the Ubuntu and Android gpu configs):
coloremoji & complexclip2_rrect_bw
Original issue's description:
> Fix GPU clipped-AA vs. non-AA drawRect discrepancy
>
> In the clip stack we were manually rounding out non-AA clip rects but leaving the hardening of non-AA drawRects up to the GPU. In some border cases the GPU can truncate rather than round out resulting in visual discrepancies.
>
> BUG=423834
>
> Committed: https://skia.googlesource.com/skia/+/933a03fecb65c83f81cf65d5cf9870c69aa379ffTBR=bsalomon@google.com,jvanverth@google.com
NOTREECHECKS=true
NOTRY=true
BUG=423834
Review URL: https://codereview.chromium.org/847033002
In the clip stack we were manually rounding out non-AA clip rects but leaving the hardening of non-AA drawRects up to the GPU. In some border cases the GPU can truncate rather than round out resulting in visual discrepancies.
BUG=423834
Review URL: https://codereview.chromium.org/839883003
This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.
for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end
BUG=skia:
Review URL: https://codereview.chromium.org/806653007
This GM is used to test the combined clipping of a complex clip (packman shape)
and a simple one (circle). We loop over all combinations of clip ops, aa/bw clip,
and inverse/non-inverse clips.
This GM triggers a current bug in the gpu clipping code which fires an assert. Thus
the skipGPU flag is set until that bug is fixed.
BUG=skia:
Review URL: https://codereview.chromium.org/798793003
This CL fixes 5 bugs related to hoisting image filters:
For image filters the src layer (the one prior to filtering) often needs to be
smaller then the final layer. This requires the saveLayer's optional bounds
to be stored (in SkLayerInfo.h and SkRecordDraw.cpp) and then used in
compute_source_rect and carried around in GrCachedLayer.
The image filters can add an extra offset to the final draw operation.
This is now computed in GrLayerHoister::FilterLayer and carried around in
GrCachedLayer.
Filtered layers must use exact matches. This is now done in GrLayerCache::lock.
The filter cache requires a valid matrix so it can compute the correct offset.
This is now done in GrLayerHoister::FilterLayer.
Filtered layers need to be drawn with drawSprite while unfiltered (and therefore
hopefully atlased) layers can be drawn with drawBitmap. This is now done in
draw_replacement_bitmap.
Committed: https://skia.googlesource.com/skia/+/702eb9622102599d94ab6798e6227cf29f48c2d3
Review URL: https://codereview.chromium.org/803183003
Reason for revert:
Breaking DM
Original issue's description:
> Fix layer hoisting image filter corner cases
>
> This CL fixes 5 bugs related to hoisting image filters:
>
> For image filters the src layer (the one prior to filtering) often needs to be
> smaller then the final layer. This requires the saveLayer's optional bounds
> to be stored (in SkLayerInfo.h and SkRecordDraw.cpp) and then used in
> compute_source_rect and carried around in GrCachedLayer.
>
> The image filters can add an extra offset to the final draw operation.
> This is now computed in GrLayerHoister::FilterLayer and carried around in
> GrCachedLayer.
>
> Filtered layers must use exact matches. This is now done in GrLayerCache::lock.
>
> The filter cache requires a valid matrix so it can compute the correct offset.
> This is now done in GrLayerHoister::FilterLayer.
>
> Filtered layers need to be drawn with drawSprite while unfiltered (and therefore
> hopefully atlased) layers can be drawn with drawBitmap. This is now done in
> draw_replacement_bitmap.
>
> Committed: https://skia.googlesource.com/skia/+/702eb9622102599d94ab6798e6227cf29f48c2d3TBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/790643009
This CL fixes 5 bugs related to hoisting image filters:
For image filters the src layer (the one prior to filtering) often needs to be
smaller then the final layer. This requires the saveLayer's optional bounds
to be stored (in SkLayerInfo.h and SkRecordDraw.cpp) and then used in
compute_source_rect and carried around in GrCachedLayer.
The image filters can add an extra offset to the final draw operation.
This is now computed in GrLayerHoister::FilterLayer and carried around in
GrCachedLayer.
Filtered layers must use exact matches. This is now done in GrLayerCache::lock.
The filter cache requires a valid matrix so it can compute the correct offset.
This is now done in GrLayerHoister::FilterLayer.
Filtered layers need to be drawn with drawSprite while unfiltered (and therefore
hopefully atlased) layers can be drawn with drawBitmap. This is now done in
draw_replacement_bitmap.
Review URL: https://codereview.chromium.org/803183003
Remove SkLCGRandom. We already decided the new one was better, which is
why we wrote the new SkRandom.
Convert GMs that were using SkLCGRandom to use the improved SkRandom.
Motivated by the fact that these GMs draw differently on some runs. We
believe this to be a result of using the old SkLCGRandom.
Add each of the tests that were using SkLCGRandom to ignore-tests.txt,
since we expect they'll draw differently using SkRandom.
Move a trimmed down version of SkLCGRandom into SkDiscretePathEffect.
In order to preserve the old behavior, trim down SkLCGRandom to only
the methods used by SkDiscretePathEffect, and hide it in
SkDiscretePathEffect's cpp file.
BUG=skia:3241
Review URL: https://codereview.chromium.org/805963002
Gives more flexibility to the caller to decide whether to use the
encoded data returned by refEncodedData().
Provides an implementation that supports the old version of
SkPicture::serialize().
TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
BUG=skia:3190
Review URL: https://codereview.chromium.org/784643002
MULTILINE, ^, and $ work based on the platform, but the files being
parsed are from other platforms. As a result, the current code for
extracting the actual_results.json version will not find it in
logfiles produced on Windows when run on Mac.
The code for extracting the exact actual_results.json file to use
from a logfile is itself something of a hack, as this information
should be provided ina more structured manner. This proposed
method of finding the exact file is no worse than the old one, and
in cases like above, better.
Review URL: https://codereview.chromium.org/789253002
In addition, NVPR makes this very complicated, and I haven't quite figured out a good way to handle it, so for now color and coverage DO live on optstate, but I will figure out some way to refactor that in future CLs.
BUG=skia:
Review URL: https://codereview.chromium.org/783763002
Reason for revert:
Compilation is failing on some bots
Original issue's description:
> Replace EncodeBitmap with an interface.
>
> Gives more flexibility to the caller to decide whether to use the
> encoded data returned by refEncodedData().
>
> Provides an implementation that supports the old version of
> SkPicture::serialize().
>
> TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
>
> BUG=skia:3190
>
> Committed: https://skia.googlesource.com/skia/+/0c4aba6edb9900c597359dfa49d3ce4a41bc5dd1TBR=reed@google.com,scroggo@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:3190
Review URL: https://codereview.chromium.org/787833002
Gives more flexibility to the caller to decide whether to use the
encoded data returned by refEncodedData().
Provides an implementation that supports the old version of
SkPicture::serialize().
TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
BUG=skia:3190
Review URL: https://codereview.chromium.org/784643002
Reason for revert:
break many gm's
Original issue's description:
> Make all blending up to GrOptDrawState be handled by the xp/xp factory.
>
> In this cl the blending information is extracted for the xp and stored in the ODS
> which is then used as it currently is. In the follow up cl, an XP backend will be added
> and at that point all blending work will take place inside XP's.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/7c66342a399b529634bed0fabfaa562db2c0dbd4TBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/766653008
In this cl the blending information is extracted for the xp and stored in the ODS
which is then used as it currently is. In the follow up cl, an XP backend will be added
and at that point all blending work will take place inside XP's.
BUG=skia:
Review URL: https://codereview.chromium.org/759713002
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
This new GM visualizes the fast bounds computed by various image-filter-based SkPaints. This is lead up to fixing some issues in fast bound computation.
BUG=418417
Review URL: https://codereview.chromium.org/788613003
Currently server.py --rietveld-issue will crash if there are any
unstarted trybots on the latest patch. Instead of crashing, warn
that the bot hasn't started yet.
Review URL: https://codereview.chromium.org/758793003
