Reason for revert:
The broke the PDFium build. See
https://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-x86_64-Release-PDFium/builds/2094
Original issue's description:
> Move uils and sksl to a common sources GYP file.
>
> This is for the coalescing of sources in one GYP file to improve GN runtime. If
> this is successful, the other sources lists will also be merged into this one
> file.
>
> Inlines "../src" and "../include" for skia_source_dir and skia_include_dir. Evaluating these with GYP's variable expansion is annoying since I think another layer of nesting is required. Coding these explicitly is also more clear. This used to be required because Chromium would reference these .gypi files directly with a different path, but this no longer happens.
>
> Removes the chromium defines gypi which is no longer referenced.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302723005
>
> Committed: https://skia.googlesource.com/skia/+/39f7a10a04a914384944d8bf62621144ac4eeaa3TBR=mtklein@chromium.org,brettw@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2317683002
This is for the coalescing of sources in one GYP file to improve GN runtime. If
this is successful, the other sources lists will also be merged into this one
file.
Inlines "../src" and "../include" for skia_source_dir and skia_include_dir. Evaluating these with GYP's variable expansion is annoying since I think another layer of nesting is required. Coding these explicitly is also more clear. This used to be required because Chromium would reference these .gypi files directly with a different path, but this no longer happens.
Removes the chromium defines gypi which is no longer referenced.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302723005
Review-Url: https://codereview.chromium.org/2302723005
We've migrated SkHwuiRenderer into the Android Framework as
android::uirenderer::TestWindowContext in response to an internal
bug; we now delete that class and change our build references here.
R=djsollen@google.com
Review URL: https://codereview.chromium.org/1407053009
It's only used by a couple unit tests. We have other ways of getting
the same quality testing of our ref-count code now (e.g. TSAN).
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac10.9-Clang-x86_64-Release-CMake-Trybot
Review URL: https://codereview.chromium.org/1408213005
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
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
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
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
Duplicate code from the HWUI backends for DM and nanobench
moves into a single place, saving a hundred lines or more of
cut-and-paste.
There's some indication that this increases the incidence of
SkCanvas "Unable to find device for layer." warnings, but no
clear degradation in test results.
R=djsollen@google.com,mtklein@google.com
BUG=skia:3589
Review URL: https://codereview.chromium.org/1036303002
one common spot. (It's incomplete, and has had bugs, so it's not
like we can confidently write once, copy-paste, and not maintain
again.)
Because SkPathEffect::exposedInAndroidJavaAPI() only builds in the
Android Framework, we might want to make all this code Framework-only?
R=djsollen@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/1021823003
From inside GrContext, we have a need to create an SkPath an original path and
some dashing info. We do not have access to the original path effect so we need
a way to make the FilterPath function accessible outside of the effect. So I moved
the core filterPath code (and all need helper functions) out of SkDashPathEffect
and created a SkDashPath in utils to store these helper functions.
BUG=skia:
R=bsalomon@google.com, reed@google.com, rmistry@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/314623004
This generalizes and shares the solution found for a similar issue with
GDI. The issue is that the text size is applied early, and the rest of
the transformation late. This allows us to isolate and independently
control the text size from the rest of the transformation.
R=reed@google.com
Review URL: https://codereview.chromium.org/213153006
git-svn-id: http://skia.googlecode.com/svn/trunk@14201 2bbb7eff-a529-9590-31e7-b0007b416f81
The main meat of things is in SkThreadPool. We can now give SkThreadPool a
type for each thread to create and destroy on its local stack. It's TLS
without going through SkTLS.
I've split the DM tasks into CpuTasks that run on threads with no TLS, and
GpuTasks that run on threads with a thread local GrContextFactory.
The old CpuTask and GpuTask have been renamed to CpuGMTask and GpuGMTask.
Upshot: default run of out/Debug/dm goes from ~45 seconds to ~20 seconds.
BUG=skia:
R=bsalomon@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/179233005
git-svn-id: http://skia.googlecode.com/svn/trunk@13632 2bbb7eff-a529-9590-31e7-b0007b416f81
This patch includes a modified version of Chrome's trace_event.h, which provides
tracing macros that can easily integrate into the about://tracing framework.
Currently the macros link to a default implementation of the (narrow) tracing
class SkDefaultEventTracer which does nothing; next step will be to have Chrome
subclass the SkEventTracer with a shim that bolts Skia's trace events to its own,
allowing Skia's trace events to show up in about://tracing.
I've verified that this file builds properly, and when I added a simple scoped
TRACE_EVENT0 to SkCanvas::drawRect, along with some debug prints in the NOP
implementation of tracing, I saw what I expected printed to the screen.
BUG=skia:
R=nduca@chromium.org, reed@google.com, mtklein@google.com, bsalomon@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/149563004
git-svn-id: http://skia.googlecode.com/svn/trunk@13256 2bbb7eff-a529-9590-31e7-b0007b416f81
