SkTemplates.h contains a number of Skia specific utilities which are
not designed for external use. In addition to reducing the external
support burden, this will allow Skia to freely refactor this file.
Review URL: https://codereview.chromium.org/1272293004
This also:
makes the SkLightingShader handle normal maps where the rects aren't aligned between the diffuse and normal maps.
adds a light aggregating class (Lights) to SkLightingShader (along with a Builder nested class).
Split out of https://codereview.chromium.org/1261433009/ (Add SkCanvas::drawLitAtlas call)
Review URL: https://codereview.chromium.org/1291783003
Reason for revert:
derek + Test-Win8-MSVC-ShuttleB-CPU-AVX2-x86_64-Debug
Original issue's description:
> Have DM manually encode its .png outputs.
>
> This eliminates some variability on various axes: different PNG encoders, different libpng versions, different formats (RGB, indexed), different unpremultiplication, different sRGB tags.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/3cc0dfffb70c0bd08ed8899efcd2e98da86a6ec7TBR=stephana@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1297383002
This eliminates some variability on various axes: different PNG encoders, different libpng versions, different formats (RGB, indexed), different unpremultiplication, different sRGB tags.
BUG=skia:
Review URL: https://codereview.chromium.org/1304443002
It's sort of pointless: all our clients that will have SSE2 at runtime have it
unconditionally at compile time, so the functions in namespace portable will
pick up the SSE2 code. The procs in SkOpts_sse2.o were just duplicate code.
A couple of the procs we had in _sse2.cpp can benefit slightly when compiled
with SSSE3. I've moved those to _ssse3.cpp. This should lead to small speedups
on platforms like Linux and Windows that have a baseline of SSE2.
Similarly, I've removed the call to Init_neon() when NEON is available globally... it's a no-op.
Renaming namespace portable to something clearer is TBD.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1294213002
Reason for revert:
This will make the google3 roll awkward. Reverting.
Original issue's description:
> Depend on ETC1 via DEPS instead of a direct third_party checkin.
>
> Yes, this does mean we'll check out ~40M of code for 2 files...
>
> I think these trybots are moot... they gclient sync before patching.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/ca01d179347b5e848ded97c8228b79ffc6b5e7bfTBR=robertphillips@google.com,djsollen@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1290913008
Yes, this does mean we'll check out ~40M of code for 2 files...
I think these trybots are moot... they gclient sync before patching.
BUG=skia:
Review URL: https://codereview.chromium.org/1296253003
Many of these were excluded from the build for bots that no longer exist.
Will fix up anything that starts failing using dm_flags.py.
BUG=skia:2326,skia:2313, skia:1978
Review URL: https://codereview.chromium.org/1290943004
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
Rename to SkDeflate so Chromium builders continue to work
Next, we change remove SkFlate from Chromium build files, then we can delete SkFlate.
Review URL: https://codereview.chromium.org/1285913002
When possible use run-time checks (via SkDocument::CreatePDF)
When PDF is disabled, do not compile tests/PDF*.cpp
Review URL: https://codereview.chromium.org/1278403006
Compile SkJpegCodec and SkImageDecoder_libjpeg with
chromium's libjpeg-turbo. SkImageDecoder_libjpeg still uses
libjpeg on Android and the Android framework. SkJpegCodec is
still not compiled on the Android framework.
BUG=skia:
Review URL: https://codereview.chromium.org/1275773004
libwebp has a fix for [1]. Update to the commit that contains the fix.
Update libwebp.gypi, corresponding to libwebp's latest makefile.
Turn back on DM testing for scaled webp, now that it should no longer
use uninitialized memory.
Fix a warning in config.h
[1] https://code.google.com/p/webp/issues/detail?id=254
BUG=skia:4038
Review URL: https://codereview.chromium.org/1280073002
Will regress behavior on gold on test32bfv4.bmp, where we
will no longer fix transparent decodes.
TODO: Start fixing transparent decodes again, or decide
that we don't want to fix them and remove isTransparent
from SkSwizzler. I think this may become more clear when I
start implementing the scanline decoder.
BUG=skia:
Review URL: https://codereview.chromium.org/1258863008
Pretty vanilla translation. I cleaned up who calls whom a little.
Used to be utils -> opts -> utils, now it's just utils -> opts.
I may follow up with a pass over the NEON code for readability
and to clean up dead code.
This turns on NEON A8->R11EAC conversion for ARMv8.
Unit tests which now hit the NEON code still pass.
I can't find any related bench.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1273103002
Traditionally, SkTraceEvent.h was manually kept in sync with base/trace_event/trace_event.h, with project-specific parts intermixed, and tended to drift out of sync a lot (mainly in Blink, less so in Skia).
The SkTraceEventCommon.h now has only the cross-project parts, and can be copy-pasted verbatim between projects (it's an identical copy of base/trace_event/trace_event_common.h), meaning SkTraceEvent.h shouldn't go out of sync as it has before.
BUG=skia:
[mtklein mucking around below here]
NOPRESUBMIT=true
CQ_EXCLUDE_TRYBOTS=client.skia.fyi:skia_presubmit-Trybot
Review URL: https://codereview.chromium.org/1270783002
Nothing too fancy.
Direction enums become enum classes so they don't get all confused. An
alternative is to create one single Direction enum that both blur and
morphology opts use.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1267343004
Motivation: maintaining this code doesn't seem worth the time,
since no one seems to be using it. If someone wants to use it
in the future, just revert this CL.
Review URL: https://codereview.chromium.org/1266093003
Prior to this CL, if a client wanted to decode scanlines, they had to
create an SkCodec in order to get an SkScanlineDecoder. This introduces
complications if input data is not easily shared between the two
objects.
Instead, add methods to SkScanlineDecoder for creating a new one from
input data, and remove the creation functions from SkCodec.
Update DM and tests.
Review URL: https://codereview.chromium.org/1267583002
+268 -535 lines
I also rearranged the code a little bit to encapsulate itself better,
mostly replacing static helper functions with lambdas. This also
let me merge the SSE2 and SSE4.1 code paths.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1264103004
Renames Sk4pxXfermode.h to SkXfermode_opts.h,
and refactors it a tiny bit internally.
This moves xfermode optimization from being "compile-time everywhere but NEON"
to simply "runtime everywhere". I don't anticipate any effect on perf or
correctness.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1264543006
With this new arrangement, the benefits of inlining sk_memset16/32 have changed.
On x86, they're not significantly different, except for small N<=10 where the inlined code is significantly slower.
On ARMv7 with NEON, our custom code is still significantly faster for N>10 (up to 2x faster). For small N<=10 inlining is still significantly faster.
On ARMv7 without NEON, our custom code is still ridiculously faster (up to 10x) than inlining for N>10, though for small N<=10 inlining is still a little faster.
We were not using the NEON memset16 and memset32 procs on ARMv8. At first blush, that seems to be an oversight, but if so it's an extremely lucky one. The ARMv8 code generation for our memset16/32 procs is total garbage, leaving those methods ~8x slower than just inlining the memset, using the compiler's autovectorization.
So, no need to inline any more on x86, and still inline for N<=10 on ARMv7. Always inline for ARMv8.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1270573002
SDL isn't an OS anyway, it's just a library views can use. Remaining
support for Brew was removed some time ago, and there are currently
no uses of SK_BUILD_FOR_PALM.
Review URL: https://codereview.chromium.org/1268573002
There is more than one way to skin this SkPathPriv.h cat.
These constructors are large enough that they probably shouldn't have
been inlined like this anyway.
BUG=skia:4126
Review URL: https://codereview.chromium.org/1253963004
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
include/views/SkOSWindow_Win.h includes it.
To move SkTHash.h to include/private, SkChecksum.h needs to go there too. To move SkChecksum.h to include/private, SkTLogic needs to go there too.
This adds a bunch of -Iinclude/private to tools.gyp I missed in the last CL.
No public API changes.
TBR=reed@google.com
BUG=skia:4126
Review URL: https://codereview.chromium.org/1260613006
I'll be moving headers from src/core to include/private, so this guarantees
that anyone who was finding them via -Isrc/core can now find them via
-Iinclude/private.
This is purely mechanical, mostly to preserve my sanity, so it's likely
(harmless) overkill.
Chromium's GYP and GN builds already set -Iinclude/private for Skia builds.
BUG=skia:4126
Review URL: https://codereview.chromium.org/1265443002
This doesn't really do anything yet. It's just the CPU detection code, skeleton new .cpp files, and a few little .gyp tweaks.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1255193002
The Android framework was failing on conditions in
libjpeg-turbo.gyp, even though libjpeg-turbo is listed
in dependencies! for the framework (maybe because I
forgot to add export_dependent_settings!). This is fixed
by rearranging the gyp file.
BUG=skia:
Review URL: https://codereview.chromium.org/1249003002
If we ever want to allow the command buffer as a skia gles2 backend,
we need a more up to date version of ANGLE, specifically there are
4 defines that differ between newer and older versions of ANGLE which
we use in skia, I've updated these in this change.
I'm not quite sure if what I've done for the 'angle_path' is correct,
I tried setting it to a path relative to skia, and to '<(DEPTH)', both
of which do not compile correctly, only '../' worked.
Committed: https://skia.googlesource.com/skia/+/db0b1e796ddbd08e6be8a666537318b1c0e2ce56
Review URL: https://codereview.chromium.org/1244843003
Visual Studio 2015 has additional warnings around noexcept and
disabling exceptions, which can be worked around with the
(undocumented) _HAS_EXCEPTIONS macro.
Visual Studio 2013 and 2015 have roundf in math.h, so use it to
avoid extra work and casts.
We avoid using cmath, as it undefs isfinite on gcc, but Visual Studio
2015 no longer provides overloads of copysign from math.h (which is
actually correct). As a result, use copysignf (which is available in
math.h in 2013 and 2015) directly.
Review URL: https://codereview.chromium.org/1244173005
Reason for revert:
Compile error that the try bots didn't catch :(
Original issue's description:
> ANGLE deps roll
>
> If we ever want to allow the command buffer as a skia gles2 backend,
> we need a more up to date version of ANGLE, specifically there are
> 4 defines that differ between newer and older versions of ANGLE which
> we use in skia, I've updated these in this change.
>
> I'm not quite sure if what I've done for the 'angle_path' is correct,
> I tried setting it to a path relative to skia, and to '<(DEPTH)', both
> of which do not compile correctly, only '../' worked.
>
> Committed: https://skia.googlesource.com/skia/+/db0b1e796ddbd08e6be8a666537318b1c0e2ce56TBR=bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1245223007
If we ever want to allow the command buffer as a skia gles2 backend,
we need a more up to date version of ANGLE, specifically there are
4 defines that differ between newer and older versions of ANGLE which
we use in skia, I've updated these in this change.
I'm not quite sure if what I've done for the 'angle_path' is correct,
I tried setting it to a path relative to skia, and to '<(DEPTH)', both
of which do not compile correctly, only '../' worked.
Review URL: https://codereview.chromium.org/1244843003
It turns out that gyp (kind of) has support for cross
compiling with a different host and target. We simply
need to specify CC_host and CC_target instead of CC.
Making this change allows us to compile yasm on a Linux
host for Android.
We run into problems on Mac because
the linker on a Mac host requires different command line
arguments than the linker on the Android target. In
looking through the code for gyp itself and speaking to
Ben, it doesn't appear to me that gyp supports passing
different arguments to host and target linkers.
I would imagine that we would have similar problems on
Windows.
Below is a link to a CL that would fix this issue in gyp.
It looks like it has been dropped for a long time.
Thanks to Ben for this link!
https://chromiumcodereview.appspot.com/10795044/
Also I'm adding a link to the build instructions for Chrome
(thanks again Ben). It looks like they only support
building for Android from Linux.
https://code.google.com/p/chromium/wiki/AndroidBuildInstructions
My next steps are:
1) Getting in touch with Torne or someone else with gyp to
see if people are aware of this issue or interested in
fixing it.
2) Deciding if skia should care about this issue.
3) Deciding if skia should work around this issue.
It'd be really great to hear your thoughts on (2) and (3).
My first thought is that we shouldn't care because, as
long as we always compile the production copy of skia for
Android on Linux, we will get the fast code. Is this
a valid conclusion? Is there a way to write Android apps
on Mac that accidentally use the slower code?
If we do care, there are workarounds:
For Mac, we can check in a yasm binary - it's a little
smaller than the one I am deleting in this CL :-/
For Windows, we *might* be able to use the yasm.exe binary
already in externals (we get this from DEPS because this is
how chromium uses yasm on Windows).
Are there other platforms that we care about?
Let me know what you think!
BUG=skia:4028
DOCS_PREVIEW= https://skia.org/?cl=1239333002
Review URL: https://codereview.chromium.org/1239333002
Now that SK_SUPPORT_LEGACY_XFERMODES is unused, tons of code becomes dead.
Nothing is needed in opts/ anymore for x86.
We still do runtime NEON detection, which just duplicates Sk4pxXfermode.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1230023011
There is nothing left in the SkFontMgr_android.cpp which is specific
to Android, so allow it to be built and used on *nix platforms. This
allows for easier development and testing.
The only reason to limit to *nix platforms are the dependencies on
Expat and FreeType. This should be buildable and runnable on other
platforms when these dependencies are also available.
Review URL: https://codereview.chromium.org/1228833003
Define SK_SUPPORT_LEGACY_ONDRAWIMAGERECT when building for the
Android framework, since SkiaCanvasProxy overrides the old version
of the method.
Fixes master-skia build.
NOTRY=True
Review URL: https://codereview.chromium.org/1237903002
Using the XCode 7 beta, the file in the GYP doesn't exist, instead we get
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libz.tbd
which is a text file describing libz and pointing to /usr/lib/libz.1.dylib.
There's a weird easy fix, which is that GYP looks for things in libraries like 'libz.dylib' and pattern match translates that to '-lz' on the command line. (Infuriatingly, a literal '-lz' is interpreted as a file path...)
BUG=skia:
Review URL: https://codereview.chromium.org/1234493002
The proportion of time spent doing useful work is well over 99% in acquire(),
so outlining it doesn't hurt speed at all, and makes it much easier to pick out
on a profile.
It'd be about 50/50 work/overhead if we outlined the extremely-cheap release().
I also tried outlining some SkRefCnt methods with similar mixed results.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1212253013
This is currently only works on Linux hosts because we have checked
in a binary and does not work on Mac hosts. We are disabling until
we find a suitable solution.
BUG=skia:4028
Review URL: https://codereview.chromium.org/1228823006
Reason for revert:
Compilation failures:
../../../../../samplecode/SampleLighting.cpp:13:18: fatal error: SkGr.h: No such file or directory
Original issue's description:
> Add normal map sample
>
> This adds an example of an SkShader that does normal
> mapping. It has a single directional light and an
> ambient light.
>
> Committed: https://skia.googlesource.com/skia/+/8e0da72ba890de395c9946ec6639c9e1e7b16027TBR=reed@google.com,bsalomon@google.com,jvanverth@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1230603002
This adds an example of an SkShader that does normal
mapping. It has a single directional light and an
ambient light.
Review URL: https://codereview.chromium.org/1212813009
DEPS:
Update to pull v0.4.3 of libwebp from upstream
gyp/libwebp.gyp:
Add new files, as referenced by the gyp file used by Chromium.
resource/tests:
Add regression tests for particular images.
BUG=skia:3442
BUG=skia:3315
BUG=skia:3429
Review URL: https://codereview.chromium.org/1178013008
Tested by running on skps/sp_desk_nytimes.skp.
The output .skp had no nested draw picture calls, and the files were both 9.3M.
BUG=skia:
Review URL: https://codereview.chromium.org/1221303020
Some of this is transitive, like SkRecords.h used by SkMiniRecorder.h
used by (public) SkPictureRecorder.h.
BUG=skia:
Review URL: https://codereview.chromium.org/1217293004
Refactor separable varying location info to be stored in GrGLProgram
subclass GrGLProgram instead of storing it in GrGLPathProcessor.
Separable varyings are exactly analoguous to uniforms: they are inputs
to the shader program. Shader compile-time information about uniforms is gathered to
GrGLProgramBuilder. This information is the converted to link-time
information, uniform locations, when constructing the program. Separable
varyings need to have same lifetime model.
This is needed in the future to support path rendering in Chromium. The
Chromium pseudo-extension will expose program fragment input binding
function similar to uniform binding function. Thus the separable varying
locations need to be decided and bound before link, e.g. before
GrGLProgram is created. This will be achieved in further patches by
overloading GrGLProgramBuilder::bindProgramResourceLocations() in
GrGLNvprProgramBuilder.
BUG=chromium:344330
Review URL: https://codereview.chromium.org/1186113007
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
I'm getting this error, which is fixed by this change:
[75/76] LINK skpdiff
FAILED: c++ -m64 -pie -Wl,-rpath=\$ORIGIN/lib/ -Wl,-rpath-link=lib/ -o skpdiff -Wl,--start-group obj/tools/skpdiff/skpdiff.skpdiff_main.o obj/tools/skpdiff/skpdiff.SkDiffContext.o obj/tools/skpdiff/skpdiff.SkImageDiffer.o obj/tools/skpdiff/skpdiff.SkPMetric.o obj/tools/skpdiff/skpdiff.skpdiff_util.o obj/tools/skpdiff/skpdiff.SkDifferentPixelsMetric_cpu.o obj/gyp/libflags.a obj/gyp/libpicture_utils.a -Wl,--end-group lib/libskia.so -lrt -lz
/usr/bin/ld: obj/tools/skpdiff/skpdiff.SkDiffContext.o: undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
BUG=skia:
Review URL: https://codereview.chromium.org/1206333002
Mangle external function names to avoid conflict with libjpeg
Take advantage of direct color conversion (RGBA, BGRA, 565)
Prepare to use jpeg_skip_scanlines (when it is upstreamed)
BUG=skia:
Review URL: https://codereview.chromium.org/1180983002
The purpose is to begin separating our GLSL-specific code from
our GL-specific code, so it can be used with the GL45 platform
Review URL: https://codereview.chromium.org/1202293002
There are a number of files with 'FontConfig' in their names which
just have to do with font configuration, but nothing to do with
the FontConfig project or even with each other. This clarifies
that these files deal with parsing for the Android font manager.
Review URL: https://codereview.chromium.org/1200103008
Based on SkImageDecoder_libwebp.
TODO:
Support YUV? (Longer term - may influence our API for SkImageGenerator)
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044433002
This allows a faster implementation of our SkTaskGroup thread pool.
It also means we don't need SkCondVar (which, remember, isn't supported on XP.)
Doing some testing with SampleApp, this really cuts down on the overhead from SkTaskGroup, e.g. 30% to 10%.
BUG=skia:
Review URL: https://codereview.chromium.org/1192573003
This moves the SkFontMgr::Factory implementation which creates a
FontMgr around FontConfig into its own file, and allows the user
to create one manually.
Review URL: https://codereview.chromium.org/1189753007
Make visualbench and SampleApp build in CONSOLE mode so that we can see stdout.
I verified that by undoing the gyp modifications both tools will build as GUI.
Review URL: https://codereview.chromium.org/1185303004
We have two, one in images/, the other in codec/. As codec's the new hotness,
I left it's name vanilla and suffixed the old one.
BUG=skia:
Review URL: https://codereview.chromium.org/1185733002
This is an alternate version of GrAAConvexPathRenderer which handles
curves by first flattening them to straight lines.
BUG=skia:
Review URL: https://codereview.chromium.org/1158803002
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 CL is ugly but it:
removes the stored SkGpuDevice back pointer from GrTextContext (at the cost of passing more parameters)
moves SkGpuDevice::internalDrawPath to GrDrawContext::drawPathFull
Unfortunately, the GrTextContext-derived classes still need the SkGpuDevice for filterTextFlags calls but I will try removing that in a separate CL.
Review URL: https://codereview.chromium.org/1157773003
