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
It's super tedious to keep setting it every time I rerun ./gyp_skia.
Doesn't look like it'll bother the bots.
BUG=skia:
Review URL: https://codereview.chromium.org/1053493005
It can be silenced or not with one flag.
Always print when building for the android framework.
Also remove the meaningless define of override to override.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1032093004
./gyp_skia -Dskia_fast=1 will
- always optimize for the current machine as much as possible
- drop the frame pointer
- optimize floating point arithmetic ignoring IEEE compliance
This allows things like 3-argument VEX prefix SSE instructions and
NEON autovectorization, and can give some seriously helpful clues
about how to rearrange floating point math for speed.
I've been having trouble with LTO linking, so I'll leave that out for now.
I don't think we should set up bots with this mode. -ffast-math means
I'm forced to run DM with --match ~Blend ~Path ~Rect ~Math ~Scalar
~Matrix ~Point before it passes, which is a disconcerting chunk of tests
to disable (including all of PathOps).
BUG=skia:
Review URL: https://codereview.chromium.org/1036533003
Unprotected reads -> relaxed reads.
Unprotected write -> relaxed write.
The only unprotected write we had was in SkTraceEvent, which it looks like we nabbed from Chrome at some point and changed only to silence TSAN. Chrome's version uses AtomicWord / NoBarrier_Load / NoBarrier_Store, which boils down to the same as here, intptr_t / relaxed load / relaxed store.
This leaves one place where we're lying a bit to TSAN, in include/core/SkLazyPtr.h where we're doing a data-dependent consume load. We're telling TSAN it's consume, but telling any other compiler to compile it as relaxed, given how they all upgrade consume to acquire. This eliminates a barrier for us on ARM. How do you guys deal with this? Just use a consume memory order, take the hit, and hope compilers get smarter one day?
BUG=chromium:465721
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/996763002
- Adds miniz.c v115_r4 (latest release) to third_party.
- Merges SkDeflateWStream into SkFlate so including "miniz.c" links
without duplicating symbols.
The only interesting code change I've made is to remove the line
fImpl->fZStream.data_type = Z_BINARY;
from SkDeflateWStream::SkDeflateWStream(). miniz doesn't have Z_BINARY
defined, and as far as I can tell, both zlib and miniz ignore data_type.
We should be able to swap skflate.gyp's dependency between zlib.gyp:zlib and
zlib.gyp:miniz at will (except of course on Windows) if we're interested in
zlib itself. I've left android framework on its own zlib. I think this all
means we can stop defining SK_NO_FLATE on Windows.
I'll leave the possible cleanup of SK_NO_FLATE itself for another time. Might
be we always want to keep this dependency optional.
CQ_EXTRA_TRYBOTS=client.skia:Test-Win8-ShuttleA-HD7770-x86-Debug-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/957323003
When checking the skia_arch_type for "x86", instead of doing an
== compare, check if "x86" in skia_arch_type, so it will cover
both x86 and x86_64.
Except when we specifically want x86.
Set skia_arch_width based on "64" in skia_arch_type. No need to specify
in scripts.
In gyp_to_android.py, create a separate var_dict for x86_64.
BUG=skia:3419
Review URL: https://codereview.chromium.org/916113002
The macro is only used in CrashHandler.*
Removes SK_CRASH_HANDLER from Android's SkUserConfig, where it is not
needed.
Review URL: https://codereview.chromium.org/915663002
Mac and Windows bots are already building in C++11 mode.
This turns on the rest, mostly to see what work remains.
This will probably break a few bots. It'd be nice if we could let those
all come in as red before reverting this so I can see the full list to fix.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/779e49602a9c8f4d2799504822e01bcafbcaa534
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu13.10-GCC4.8-NaCl-Release-Trybot,Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot
Review URL: https://codereview.chromium.org/868233008
Reason for revert:
Perf-Ubuntu12, and Test-Ubuntu12, Build-Nacl all too old.
Android and Chrome OS builders look ok.
Android testers look ok. Chrome OS testers haven't run yet.
Original issue's description:
> Build in C++11 mode on Unix-like bots.
>
> Mac and Windows bots are already building in C++11 mode.
> This turns on the rest, mostly to see what work remains.
>
> This will probably break a few bots. It'd be nice if we could let those
> all come in as red before reverting this so I can see the full list to fix.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/779e49602a9c8f4d2799504822e01bcafbcaa534TBR=stephana@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/879803003
Mac and Windows bots are already building in C++11 mode.
This turns on the rest, mostly to see what work remains.
This will probably break a few bots. It'd be nice if we could let those
all come in as red before reverting this so I can see the full list to fix.
BUG=skia:
Review URL: https://codereview.chromium.org/868233008
- add -Wsign-compare, which has been catching useful issues for Kimmo;
- add -Winit-self and -Wpointer-arith to Mac builds so everyone's using
the same flags;
- try try removing -Wno-uninitialized. This was only for the old 10.6
compiler that we have warnings set as non-errors now.
BUG=skia:
Review URL: https://codereview.chromium.org/872793002
To compile SkCondVar, we already require either pthreads or Windows. This
simplifies that code to not need SK_USE_POSIX_THREADS to be explicitly defined.
We'll just look to see if we're targeting Windows, and if not, assume pthreads.
Both before and after this CL, that code will fail to compile if we're not on
Windows and don't have pthreads.
BUG=skia:
Review URL: https://codereview.chromium.org/869443003
Defining SK_DYNAMIC_ANNOTATIONS_ENABLED as 1 whenever DYNAMIC_ANNOTATIONS_ENABLED was 1
seems to be working fine for Chrome. Should be we can just use DYNAMIC_ANNOTATIONS_ENABLED.
BUG=skia:
Review URL: https://codereview.chromium.org/810513002
This adds instrumentation to check that signed integers never under- or
overflow, which is undefined behavior.
BUG=skia:3096
Review URL: https://codereview.chromium.org/702893003
ninja -C out/Debug works, and I tested out/Debug/dm --nogpu (no X yet).
The only problems encountered were:
- Like CrOS, I also needed to use the default float ABI (presumably hard).
- The strings in GrBinHashKeyTest weren't necessarily 4-byte aligned.
BUG=skia:
Review URL: https://codereview.chromium.org/746043002
Most recently introduced here: https://codereview.chromium.org/304333002
It appears these are not currently needed (I just disabled it and
successfully built).
Since we appear to be out of the transitional period, I propose we
remove them so we can know if we deprecate something Android uses
(and fix the call site).
Review URL: https://codereview.chromium.org/696063006
Reason for revert:
Not compiling in ANGLE build
Original issue's description:
> Get gpudft support working in dm, gm, nanobench and bench_pictures
>
> Adds a new config to test distance field text.
> Clean up some flags and #defines to read "distance field text",
> not "distance field fonts" to be consistent with Chromium
>
> NOTREECHECKS=true
>
> Committed: https://skia.googlesource.com/skia/+/06ba179838ba4fe187cf290750aeeb4a02a2960bTBR=bsalomon@google.com,mtklein@google.com,reed@google.com
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/707723005
Adds a new config to test distance field text.
Clean up some flags and #defines to read "distance field text",
not "distance field fonts" to be consistent with Chromium
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/699453005
Reason for revert:
Want to think about how to do this only to skialib and not to tools (gms, tests, etc.)
Original issue's description:
> No threadsafe statics.
>
> Chrome disables these for speed and code size, so we need
> to disable them to make sure our code is safe when used
> this way.
>
> int foo() {
> static int32_t atomic_thing;
> return sk_atomic_inc(&atomic_thing);
> }
>
> is not safe in Chrome. Making the static global is:
>
> static int32_t atomic_thing;
> int foo() {
> return sk_atomic_inc(&atomic_thing);
> }
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/cad5d3e264535c919b80e1e2a85407307961f221TBR=bungeman@google.com,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/649343003
Chrome disables these for speed and code size, so we need
to disable them to make sure our code is safe when used
this way.
int foo() {
static int32_t atomic_thing;
return sk_atomic_inc(&atomic_thing);
}
is not safe in Chrome. Making the static global is:
static int32_t atomic_thing;
int foo() {
return sk_atomic_inc(&atomic_thing);
}
BUG=skia:
Review URL: https://codereview.chromium.org/654663002
GCC doesn't understand -fasm-blocks or -mpascal-strings, but we don't care
about them.
While looking around in Gyp, I noticed a better way to disable warnings about
offsetof so that it doesn't tell us "disabling this warning makes no sense in C"
for every C source file we compile.
BUG=skia:
Review URL: https://codereview.chromium.org/650553002
We use this on Linux already, but for whatever reason wasn't a problem on iOS
until using it in SkPaint. Mac 10.7 and 10.8 are showing this warning too,
but seems -Werror is not enabled.
CQ_EXTRA_TRYBOTS=tryserver.skia:Build-Mac10.7-Clang-Arm7-Release-iOS-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/637593002
SkRacy<T> is a zero-overhead wrapper for a T, except it also
silences race warnings when TSAN is running.
Here we apply in several classes. In SkMatrix and SkPathRef,
we use it to opportunistically cache some idempotent work.
In SkPixelRef, we wrap the genIDs. We think the worst that
can happen here is we'll increment the global next-genID a
few times instead of once when we go to get another ID.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/d5e3e6ae1b3434ad1158f441902ff65f1eeaa3a7
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot,Canary-Chrome-Win7-Ninja-x86-SharedLib_ToT-Trybot,Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371363004
This ought to get us a little ahead on the transition. Only minor fixes
are needed. The one in MemoryBench is the most interesting: what used
to unambiguously be interpreted as concatenating two string literals is
now also ambiguously a user-defined literal; adding a space
disambiguates.
BUG=skia:
R=bungeman@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/361723002
Always build the tools with JSON, but either build our own
or use the system's.
Rename skia_build_json_writer to skia_use_system_jsoncpp,
since we now always build with JSON.
Remove SK_BUILD_JSON_WRITER, which was only there so
we could build without JSON it in the framework.
BUG=skia:2448
R=djsollen@google.com, reed@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/303913002
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
