Adds a set of histogram macros to Skia, modeled after Chrome's
UMA_HISTOGRAM_* macros. These allow logging of high frequency events,
and are useful to analyze real world usage of certain features.
By default, these macros are no-ops. Users can provide a custom
header file which defines these macros if they wish to collect
histogram data. Chrome will provide such a header.
I've currently only added two macros:
- SK_HISTOGRAM_BOOLEAN - logs a true/false type relationship (whether
we are tiling a texture or not on each draw).
- SK_HISTOGRAM_ENUMERATION - logs a set of potential values (which of
a number of choices were selected for the texture upload path).
We could add more unused macros at the moment, but it seems easier to
add these as needed, WDYT?
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1652053004
Review URL: https://codereview.chromium.org/1652053004
It seems that MSVC + __vectorcall don't play well together,
so back ourselves out into a situation where we don't need it.
- Inline transfermode functions. This removes the need for SK_VECTORCALL.
- Remove 565 destination specializations.
Blending into 565 is not speed-critical enough to merit the code bloat.
- Removing 565 specializations means a bunch of Sk4px code is now dead.
8888 xfermodes generally speed up a bit from inlining, smoothly ranging from no change down to 0.65x for the fastest functions like Plus or Modulate.
565 xfermodes generally slow down because we're doing 565 -> 8888 and 8888->565 conversion serially[1] and using the stack, smoothly ranging from no change up to 2x slower for the fastest functions like Plus and Modulate.
[1] the 565->8888 conversion is actually being autovectorized
BUG=skia:4765,skia:4776
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1565223002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1565223002
DebugWriteToStderr isn't defined for Android. I'm not sure if I just didn't test compiling for Android or if this is due to a change in the base library.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1438773003
Use DumpStackTrace in SkASSERT in GOOGLE3.
There are extra assertions enabled in debug mode that cause RecordDraw_TextBounds to fail.
New include causes a naming conflict with global name "base".
Corresponding internal cl/106495354
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1423013004
This CL removes the uses of SkNEW that have resprouted since commit
385fe4d, and removes the macros entirely now that Android and Chromium
have been cleaned up to no longer depend on them.
A bunch of files implicitly depend on #include <new> from SkPostConfig.h
still though, so keep that for now. To be fixed in a followup CL.
[mtklein mucking around]
Only public API removed.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1360653004
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
The current include-what-you-use with current clang is much less
noisy and more useful than it has been in the past. This change
introduces a few IWYU directives (which are helpful documentation for
humans as well) and fixes a few sets of includes.
Review URL: https://codereview.chromium.org/1207893002
This deduplicates a few pieces of code:
- we end up with one copy of each xfer32() driver loop instead of one per xfermode;
- we end up with two* copies of each xfermode implementation instead of ten**.
* For a given Mode: Mode() itself and xfer_aa<Mode>().
** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
Performance is affected in proportion to the original xfermode speed:
fast modes like Plus take the largest proportional hit, and slow modes
like HardLight or SoftLight see essentially no hit at all.
This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
TBR=reed@google.com
No public API changes.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49da
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon-Trybot
Review URL: https://codereview.chromium.org/1242743004
Reason for revert:
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon/builds/1168/steps/build%20most/logs/stdio
Original issue's description:
> De-templatize Sk4pxXfermode code a bit.
>
> This deduplicates a few pieces of code:
> - we end up with one copy of each xfer32() driver loop instead of one per xfermode;
> - we end up with two* copies of each xfermode implementation instead of ten**.
>
> * For a given Mode: Mode() itself and xfer_aa<Mode>().
> ** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
>
> This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
>
> If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
>
> Performance is affected in proportion to the original xfermode speed:
> fast modes like Plus take the largest proportional hit, and slow modes
> like HardLight or SoftLight see essentially no hit at all.
>
> This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
>
> For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
>
> TBR=reed@google.com
> No public API changes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49daTBR=msarett@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1245273005
This deduplicates a few pieces of code:
- we end up with one copy of each xfer32() driver loop instead of one per xfermode;
- we end up with two* copies of each xfermode implementation instead of ten**.
* For a given Mode: Mode() itself and xfer_aa<Mode>().
** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.
This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.
If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent. This would result in another ~100K space savings.
Performance is affected in proportion to the original xfermode speed:
fast modes like Plus take the largest proportional hit, and slow modes
like HardLight or SoftLight see essentially no hit at all.
This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows. I've looked at the ARMv7 generated code... it looks good, even pretty.
For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference. Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.
TBR=reed@google.com
No public API changes.
BUG=skia:
Review URL: https://codereview.chromium.org/1242743004
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
This fixes two problems:
1) #include SK_SOME_DEFINE doesn't work well for all our clients.
2) Things in include/ are #including things in src/, which we don't like.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/862983002
A careful reading of the preprocessor specification indicates that
any use of the 'defined' operator outside the form of 'defined X' or
'defined ( X )' directly in the constant expression of a '#if' or
'#elif' may cause undefined behavior.
In particular, msvc is very unpredictable. The 'defined X' and
'defined ( X )' forms behave differently when created from marco
expansion, with 'defined ( X )' generally evaluating to '0L'. The
'defined X' form generally behaves more the way one would expect,
but still has a number of quirks which should simply be considered
undefined behavior.
BUG=chromium:419245
Review URL: https://codereview.chromium.org/657183002
Every doc I've found about using Android's atomics says, "stop".
"* A handful of basic atomic operations. The appropriate pthread
* functions should be used instead of these whenever possible."
"... we recommend stopping from using these functions entirely. Very fortunately, GCC provides handy intrinsics functions that work with very reasonable performance and always provide a full barrier."
As far as I can tell, there's no code generation change here: both the __sync atomics and the android_ atomics use full memory barriers. (And now with this all unified, it'll be easier to get the real wins by switching everything to __atomic atomics, which are like __sync atomics but allow control over memory barriers.)
BUG=skia:
R=bungeman@google.com, djsollen@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/305593002
git-svn-id: http://skia.googlecode.com/svn/trunk@14896 2bbb7eff-a529-9590-31e7-b0007b416f81
Mike K: please sanity check Test.cpp and skia_test.cpp
Feel free to look at the rest, but I don't expect any in depth review of path ops innards.
Path Ops first iteration used QuickSort to order segments radiating from an intersection to compute the winding rule.
This revision uses a circular sort instead. Breaking out the circular sort into its own long-lived structure (SkOpAngle) allows doing less work and provides a home for caching additional sorting data.
The circle sort is more stable than the former sort, has a robust ordering and fewer exceptions. It finds unsortable ordering less often. It is less reliant on the initial curve tangent, using convex hulls instead whenever it can.
Additional debug validation makes sure that the computed structures are self-consistent. A new visualization tool helps verify that the angle ordering is correct.
The 70+M tests pass with this change on Windows, Mac, Linux 32 and Linux 64 in debug and release.
R=mtklein@google.com, reed@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/131103009
git-svn-id: http://skia.googlecode.com/svn/trunk@14183 2bbb7eff-a529-9590-31e7-b0007b416f81
Tested in Mozilla source tree. I tried to use skia build system, but it's up to the task for cross compilation.
SkHRESULT.cpp - Use proper file name (that matters on case sensitive OSes)
SkAtomics_win.h - Don't use pragma intrinsic on GCC (this causes massive warnings)
SkOSFile_win.cpp - This one is tricky. GCC doesn't allow (void*) casts in template argument constants and INVALID_HANDLE_VALUE looks like this:
((HANDLE)(LONG_PTR)-1)
where HANDLE is typedefed to void*. Changed the code to use LONG_PTR as template argument and cast it when needed.
BUG=skia:
R=bungeman@google.com, reed@google.com
Author: cjacek@gmail.com
Review URL: https://codereview.chromium.org/198643004
git-svn-id: http://skia.googlecode.com/svn/trunk@13862 2bbb7eff-a529-9590-31e7-b0007b416f81
