This fix is necessary to correctly propagate invalidations that
are external to skia. For example, when drawing video or WebGL
into a 2D canvas in Chrome, with mipmaps enabled.
BUG=crbug.com/498356
TEST=GrTextureMipMapInvalidationTest
Review URL: https://codereview.chromium.org/1177843007
Brings in the following functionality:
ARB_draw_instanced
ARB_instanced_arrays
NV_bindless_texture
EXT_direct_state_access
KHR_debug
Also cleans up some of the NVPR extension loading.
BUG=skia:
Review URL: https://codereview.chromium.org/1185573003
Adds a new FBO type kStencil_MSFBOType that is selected whenever
NV_framebuffer_mixed_samples extension is available. In this new
FBO type a non-msaa color buffer is created with a multisampled
stencil buffer attachment.
Replaces numSamples() with separate numColorSamples and numStencilSamples
methods in RenderTarget.
In mixed samples mode non-MSAA codepaths are used to draw simple shapes,
while NVPR-rendered paths and text are rendered with a multisampled
stencil.
BUG=skia:3177
Review URL: https://codereview.chromium.org/1001503002
- 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
I haven't figured out a pithy way to have these apply to only classes
originating from SkNx, so let's just remove them. There aren't too
many use cases, and it's not really any less readable without them.
Semantically, this is a no-op.
BUG=skia:
Review URL: https://codereview.chromium.org/1167153002
Tweak some test values to pass with floats.
As expected, this regresses matrix44_setconcat_general by about 2x.
BUG=skia:
Review URL: https://codereview.chromium.org/1169813006
FreeType automatically selects the 'most Unicode' cmap available,
otherwise the default cmap is NULL. When this happens the fallback
should include the 3,0 symbol cmap, as is outlined in the Apple
TrueType documentation. This cmap should effectively be a Unicode
mapping, but exclusively in the private use area.
BUG=skia:1873,chromium:489452
Review URL: https://codereview.chromium.org/1163833003
Long lived SkImageHeap objects currently accumulate refs indefinitely.
This leads to massive memory leaks in the gpu-accelerated 2D canvas
code path. This CL does not implement a general fix for SkGPipe, but
it resolves the leak in SkDeferredCanvas (currently the only user
of SkGPipe) by resetting the image heap when the deferral queue is
flushed. This change also fixes the accounting of bytes allocated
by referenced images in order to trigger flushing heuristics
appropriately.
BUG=crbug.com/494148
Review URL: https://codereview.chromium.org/1145893007
Renames getInvariantOutput to getInvariantBlendedColor on GrXPFactory
and redefines it to not account for coverage conflation. This is the
information that all the callsites actually wanted to know.
BUG=skia:
Review URL: https://codereview.chromium.org/1161273005
Reason for revert:
gfx_unittests (under linux_asan)
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Direct leak of 368 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f7060ebdf in _cairo_image_surface_create_for_pixman_image /build/buildd/cairo-1.10.2/src/cairo-image-surface.c:158@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@Indirect leak of 256 byte(s) in 1 object(s) allocated from:@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #0 0x4cc74b in __interceptor_malloc (/b/build/slave/linux_asan/build/src/out/Release/gfx_unittests+0x4cc74b)@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@ #1 0x7f2f6c7be26a in _pixman_image_allocate /build/buildd/pixman-0.30.2/build/pixman/../../pixman/pixman-image.c:184@@@
@@@STEP_LOG_LINE@RenderTextTest.HarfBuzz_HorizontalPositions@@@@
I think they are creating a cairo surface, but it has no pixels (zero size?). In this CL, if I see no pixels, I ignore the call-back which is used to free the surface (doh).
Original issue's description:
> Revert[4] of add asserts around results from requestLock
>
> This reverts commit 19663e54c0.
>
> BUG=skia:
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/df91b73a34e3a306c93a5e320704736255c3d9f0TBR=reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1151063005
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
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
If one of the inputs to a SkMergeImageFilter was clipped away or
otherwise caused the filterImage(...) invocation for it to return
false, the entire effect would be "failed" and return false --
regardless of if it had produced a result or not.
Instead of returning false directly if filterImage(...) for a source
returned false, consider all the inputs, and then only return false if
all of them do.
BUG=chromium:489046
Review URL: https://codereview.chromium.org/1133523006
Reason for revert:
win_chromium_compile_dbg_ng
FAILED: ninja -t msvc -e environment.x86 -- E:\b\build\goma/gomacc "E:\b\depot_tools\win_toolchain\vs2013_files\VC\bin\amd64_x86\cl.exe" /nologo /showIncludes /FC @obj\third_party\skia\src\core\skia.SkBitmapHeap.obj.rsp /c ..\..\third_party\skia\src\core\SkBitmapHeap.cpp /Foobj\third_party\skia\src\core\skia.SkBitmapHeap.obj /Fdobj\skia\skia.cc.pdb
e:\b\build\slave\win\build\src\third_party\skia\include\core\skpicture.h(176) : error C2487: 'CURRENT_PICTURE_VERSION' : member of dll interface class may not be declared with dll interface
Original issue's description:
> Sketch splitting SkPicture into an interface and SkBigPicture.
>
> Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
> These cover about 89% of draw calls from Blink SKPs,
> and about 25% of draw calls from our GMs.
>
> SkPicture handles:
> - serialization and deserialization
> - unique IDs
>
> Everything else is left to the subclasses:
> - playback(), cullRect()
> - hasBitmap(), hasText(), suitableForGPU(), etc.
> - LayerInfo / AccelData if applicable.
>
> The time to record a 1-op picture improves a good chunk
> (2 mallocs to 1), and the time to record a 0-op picture
> greatly improves (2 mallocs to none):
>
> picture_overhead_draw: 450ns -> 350ns
> picture_overhead_nodraw: 300ns -> 90ns
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8b
>
> Latest blink_linux_rel:
>
> http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/61248
>
> Committed: https://skia.googlesource.com/skia/+/15877b6eae33a9282458bdb904a6d00440eca0ecTBR=reed@google.com,robertphillips@google.com,fmalita@chromium.org,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1130283004
Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
These cover about 89% of draw calls from Blink SKPs,
and about 25% of draw calls from our GMs.
SkPicture handles:
- serialization and deserialization
- unique IDs
Everything else is left to the subclasses:
- playback(), cullRect()
- hasBitmap(), hasText(), suitableForGPU(), etc.
- LayerInfo / AccelData if applicable.
The time to record a 1-op picture improves a good chunk
(2 mallocs to 1), and the time to record a 0-op picture
greatly improves (2 mallocs to none):
picture_overhead_draw: 450ns -> 350ns
picture_overhead_nodraw: 300ns -> 90ns
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8b
Latest blink_linux_rel:
http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/61248
Review URL: https://codereview.chromium.org/1112523006
Cheap (one contour) paths can be evaluated and reversed as needed with a minimum of checking, but multi-contour paths invoke the regular path ops machinery to determine who is contained by whom.
More tests need to be added to verify that all corner cases are considered, but this fixes the cases in the bug thus far.
R=fmalita@chromium.orgTBR=reed@google.com
BUG=skia:3838
Review URL: https://codereview.chromium.org/1129193006
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
0x8001 / 0x7fff don't seem to work, but we were close: 0x8000 does.
I plan to use this to implement the Difference xfermode,
and it seems generally handy.
BUG=skia:
Review URL: https://codereview.chromium.org/1133933004
The rewrite of path ops caused the inner contour direction to be reversed.
This exposed an existing bug in path ops builder, namely that the implicit
winding of the internal sum path could hide inner contours if they ended
up in the wrong direction.
Setting the sum path's fill type to even-odd ensures that the inner
contours aren't discarded.
R=fmalita@chromium.org
BUG=skia:3838
Review URL: https://codereview.chromium.org/1126193004
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
Confirm that no path ops tests are flaky, and clean up errors around
that. The test framework was incorrectly checking for >= MAX_ERRORS for
failure and <= MAX_ERRORS for success.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1140563003
Improve line/curve coincident detection and resolution. This fixed the remaining simple failures.
When an edge is unsortable, use the ray intersection to determine the angles' winding.
Deal with degenerate segments.
TBR=reed@google.com
BUG=skia:3588,skia:3762
Review URL: https://codereview.chromium.org/1140813002
This replacement shoots axis-aligned rays through all intersecting edges to find the outermost one either horizontally or vertically. The resulting code is smaller and twice as fast.
To support this, most of the horizontal / vertical intersection code was rewritten and standardized, and old code supporting the top-directed winding was deleted.
Contours were pointed to by an SkTDArray. Instead, put them in a linked list, and designate the list head with its own class to ensure that methods that take lists of contours start at the top. This change removed a large percentage of memory allocations used by path ops.
TBR=reed@google.com
BUG=skia:3588
Review URL: https://codereview.chromium.org/1111333002
Reason for revert:
speculative revert to fix failures in DEPS roll
Original issue's description:
> Sketch splitting SkPicture into an interface and SkBigPicture.
>
> Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
> These cover about 89% of draw calls from Blink SKPs,
> and about 25% of draw calls from our GMs.
>
> SkPicture handles:
> - serialization and deserialization
> - unique IDs
>
> Everything else is left to the subclasses:
> - playback(), cullRect()
> - hasBitmap(), hasText(), suitableForGPU(), etc.
> - LayerInfo / AccelData if applicable.
>
> The time to record a 1-op picture improves a good chunk
> (2 mallocs to 1), and the time to record a 0-op picture
> greatly improves (2 mallocs to none):
>
> picture_overhead_draw: 450ns -> 350ns
> picture_overhead_nodraw: 300ns -> 90ns
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8bTBR=reed@google.com,robertphillips@google.com,mtklein@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1130333002
Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
These cover about 89% of draw calls from Blink SKPs,
and about 25% of draw calls from our GMs.
SkPicture handles:
- serialization and deserialization
- unique IDs
Everything else is left to the subclasses:
- playback(), cullRect()
- hasBitmap(), hasText(), suitableForGPU(), etc.
- LayerInfo / AccelData if applicable.
The time to record a 1-op picture improves a good chunk
(2 mallocs to 1), and the time to record a 0-op picture
greatly improves (2 mallocs to none):
picture_overhead_draw: 450ns -> 350ns
picture_overhead_nodraw: 300ns -> 90ns
BUG=skia:
Review URL: https://codereview.chromium.org/1112523006
This totally overhauls the implementation to use ordinary inheritance-based type erasure. I give up for now getting my manual vtable shenanigans to work with MSVC. Still those same "expected ; before ), also expected ) before ;" errors.
I added support for uninitialized SkFunctions and operator=(), because it was fairly straightforward with this implementation.
The main downside here is that I've removed the inline implementation. All SkFunctions involve a heap allocation, even when just wrapping function pointers.
BUG=skia:
Review URL: https://codereview.chromium.org/1056673002
Motivation: PDF/A metadata will need the creation date embedded in it.
Also, GetDateTime returns local time in Win32. This now behaves the
same as on Unix systems.
BUG=skia:3110
Review URL: https://codereview.chromium.org/1109593002
Updates GrXferProcessor to read directly from the RT texture when
texture barriers are supported and it needs to know the dst color.
Also adds the notion of an Xfer barrier and uses it to issue texture
barriers when the XP will read the RT.
BUG=skia:
Review URL: https://codereview.chromium.org/1040303002
All but 17 extended tests work.
A helper function is privately added to SkPath.h to permit a test to modify a given point in a path.
BUG=skia:3588
Review URL: https://codereview.chromium.org/1107353004
WIP
- Can accumulate (write) data in one thread, and share snapshots of it in other threads
... e.g. network accumulates image data, and periodically we want to decode/draw it
- If this sort of thing sticks, should we promote SkData to have the same generality as
SkRBuffer?
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1106113002
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
Move line dashing logic from GrContext::drawPath to
GrDashLinePathRenderer. This makes it possible to let path renderers render arbitrary dashed paths.
End goal is to implement dashing in GrStencilAndCoverPathRenderer.
Review URL: https://codereview.chromium.org/1100073003
Chrome wants to call this more often, and it's quite slow today.
Seems like this could be clearer if SkPictureUtils::ApproxBytesUsed() were SkPicture::approxBytesUsed().
BUG=chromium:471873
Review URL: https://codereview.chromium.org/1090943004
More nullptr checks for factories I have added.
Other checks more Yoda-like I have made. (Skia style this is.)
BUG=skia:
Review URL: https://codereview.chromium.org/1086393004
Extended tests (150M+) run to completion in release in about 6 minutes; the standard test suite exceeds 100K and finishes in a few seconds on desktops.
TBR=reed
BUG=skia:3588
Review URL: https://codereview.chromium.org/1037953004
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
Enables basic decoding for jpegs
Includes rewinding
565, YUV, and Jpeg encoding are not yet implemented
BUG=skia:3257
Review URL: https://codereview.chromium.org/1076923002
These will underly the SkPMFloat-like class for uint16_t components.
Sk4h will back a single-pixel version, and Sk8h any larger number than that.
BUG=skia:
Review URL: https://codereview.chromium.org/1088883005
The bmp codec currently returns kIncompleteInput
when the stream is truncated, which we treat as a
partial success. However, we neglect the fill the
remaining pixels in the image, leaving these
uninitialized.
This CL addresses this problem by initializing the
remaining pixels in the image to default values.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1075243003
We may want to enable swizzles to 565
for images that are encoded in a format
similar to 565, however, we do not want
to take images that decode naturally to
kN32 and then convert them to 565.
***Enable swizzles to kIndex_8. For images
encoded in a color table format, we suggest
that they be decoded to kIndex_8. When we
decode, we only allow conversion to kIndex_8
if it matches the suggested color type (except
wbmp which seems good as is).
***Modify dm to test images that decode to
kIndex_8.
BUG=skia:3257
BUG=skia:3440
Review URL: https://codereview.chromium.org/1055743003
This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
I don't see any significant effect on large picture recording times from our .skps.
BUG=chromium:470553
Committed: https://skia.googlesource.com/skia/+/e2dd9408cd711777afaa9410427fb0d761ab004a
Review URL: https://codereview.chromium.org/1061783002
This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
I don't see any significant effect on large picture recording times from our .skps.
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1061783002
SkCodec::NewFromStream claims to delete the passed in SkStream on
failure. This allows the caller to pass an SkStream to the function
and not worry about deleting it depending on the return value.
Most of our SkCodecs did not honor this contract though. Update them
to delete the stream on failure. Further, update SkCodec::NewFromStream
to delete the stream if it did not match any subclass, and delete the
SkCodec if we decided to return NULL because it was too big.
Add a test which tests streams which represent the beginnings of
supported format types but do not contain enough data to create an
SkCodec. The interesting part of the test is when we run it on ASAN,
which will report that we leaked something without the other changes.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1058873006
Add a virtual method on SkStream which will do a "peek" some bytes, so
that those bytes are read, but the next call to read will be
unaffected.
Implement peek for SkMemoryStream, where the implementation is simple
and obvious.
Implement peek on SkFrontBufferedStream.
Add tests.
Motivated by decoding streams which cannot be rewound.
TBR=reed@google.com
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044953002
