Add SkSmallAllocator, a template for allocating small (as defined by the
instantiation) objects without extra calls to new. Add a helper macro to
make using it simple.
Remove SkTemplatesPriv.h, whose behavior is replaced by SkSmallAllocator.
The old SK_PLACEMENT_NEW had the following drawbacks:
- Easily confused with SkNEW_PLACEMENT.
- Requires passing around lots of void*s along with the storageSize.
- Requires using a separate class for deleting it.
- We had multiple ways Auto objects for deleting in different places.
- It always did a straight heap allocation on Windows, meaning Windows
did not get any advantages from the confusing code.
The new SkSmallAllocator simplifies things:
- It is clear about what it does.
- It takes care of the deletion in one place that is automatically
handled.
Further, the new class can be used to create more than one object. This
is in preparation for BUG=skia:1976, for which we would like to create
a new object without extra heap allocations. The plan is to create both
the blitter and the new object on the stack using the SkSmallAllocator.
Add a new test for SkSmallAllocator.
SkShader.h:
Move the private version of CreateBitmapShader to SkBitmapProcShader
(which already has the implementation) and remove the friend class
(which was only used to call this private function). This allows
SkSmallAllocator to reside in the private src/ directory.
SkBitmapProcShader:
Move CreateBitmapShader and the macro for the storage size here. With
the macro in a (private) header, the (private) headers with function
declarations (which now depend on the storage size used) can see the
macro.
Use SkSmallAllocator in CreateBitmapShader.
Change the macro to kBlitterStorageByteCount, since SkSmallAllocator
takes a byte count as its template parameter.
SkBlitter:
Use the SkSmallAllocator.
Remove Sk3DShader::fKillProc and SkAutoCallProc. Both of their
behaviors have been moved into SkSmallAllocator (SkAutoCallProc was
unnecessary anyway, because the only time we ever used it we also
called detach(), so its auto behavior never happened).
Create the Sk3DShader on the stack, if there's room.
Remove the helper version of Choose, which was unused.
SmallAllocatorTest:
Test for the new class.
The rest:
Use SkSmallAllocator.
BUG=skia:1976
R=reed@google.com, mtklein@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/179343005
git-svn-id: http://skia.googlecode.com/svn/trunk@13696 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
Also:
- make GrMemoryPoolBenches threadsafe
- some tweaks to various DM code
- rename GM::shortName() to getName() to match benches and tests
On my desktop, (289 GMs, 617 benches) x 4 configs, 227 tests takes 46s in Debug, 14s in Release. (Still minutes faster than running tests && bench && gm.) GPU singlethreading is definitely the limiting factor again; going to reexamine whether that's helpful to thread it again.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/178473006
git-svn-id: http://skia.googlecode.com/svn/trunk@13603 2bbb7eff-a529-9590-31e7-b0007b416f81
- refactor GYPs and a few flags
- make GPU tests grab a thread-local GrContextFactory when needed as we do in DM for GMs
- add a few more UI features to make DM more like tests
I believe this makes the program 'tests' obsolete.
It should be somewhat faster to run the two sets together than running the old binaries serially:
- serial: tests 20s (3m18s CPU), dm 21s (3m01s CPU)
- together: 27s (6m21s CPU)
Next up is to incorporate benches. I'm only planning there on a single-pass sanity check, so that won't obsolete the program 'bench' just yet.
Tested: out/Debug/tests && out/Debug/dm && echo ok
BUG=skia:
Committed: http://code.google.com/p/skia/source/detail?r=13586R=reed@google.com, bsalomon@google.com, mtklein@google.com, tfarina@chromium.org
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/178273002
git-svn-id: http://skia.googlecode.com/svn/trunk@13592 2bbb7eff-a529-9590-31e7-b0007b416f81
- refactor GYPs and a few flags
- make GPU tests grab a thread-local GrContextFactory when needed as we do in DM for GMs
- add a few more UI features to make DM more like tests
I believe this makes the program 'tests' obsolete.
It should be somewhat faster to run the two sets together than running the old binaries serially:
- serial: tests 20s (3m18s CPU), dm 21s (3m01s CPU)
- together: 27s (6m21s CPU)
Next up is to incorporate benches. I'm only planning there on a single-pass sanity check, so that won't obsolete the program 'bench' just yet.
Tested: out/Debug/tests && out/Debug/dm && echo ok
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com, tfarina@chromium.org
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/178273002
git-svn-id: http://skia.googlecode.com/svn/trunk@13586 2bbb7eff-a529-9590-31e7-b0007b416f81
Motivation:
I have downloaded a barebones Linux system built for 64-bit ARM
from linaro.org and a ARMv8 Foundation Model from arm.com to run
it on. This will let us build and test Skia on ARM64 before we
aquire hardware to allow that. This CL introduces the changes to
the build files necessary to build Skia on a barebones embedded
Linux system. I tested it with the aarch64 GCC compiler provided
by linaro.org.
Changes:
Add a "barelinux" target_os for the DEPS file. Add an optional
git download of zlib.
Changes to gyp files: these changes abstract out libpng, libz, and
giflib so that images.gyp doesn't know whether they are static or
dynamically linked. I also add the variables skia_giflib_static,
skia_libpng_static, skia_zlib_static, and skia_freetype_static,
all of which default to false but when set to true will override
the behavior of the giflib, libpng, zlib, and freetype build
targets to require them to build statically. Also, the
skia_no_fontconfig variable turns off use of the fontconfig service.
Scripts in platform_tools/barelinux/bin:
arm64_download - this script downloads the Linaro's ARMv8 Aarch64
toolchain and minimal embedded Linux system as well as ARM's
foundation model. The required files are mirrored on Google
Cloud. The script then starts a emulated Arm64 Linux system in
the background. After the boot is complete, you can SSH into the
system at port 8022 via user@localhost. The SSH key will be
downloaded into the working directery as well.
download_deps - Uses gclient to download Skia's dependencies for a
bare Linux system (the normal dependecies plus giflib, libpng, and
zlib.)
barelinux_make - this script builds a version of skia that does
not depend on external libraries, perfect for putting in an
embedded system running Linux. Assumes you have run download_deps
first.
To test:
To build a barelinux target, use the barelinux_make script.
To build for a armv8 system: skia_arch_type=arm arm_neon=0 armv7=1
armv8=1 arm_thumb=0 skia_arch_width=64 and set the CC and CXX
variables to point at the cross-compiler downloaded by
arm64_download.
R=djsollen@google.com, scroggo@google.com, borenet@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/152513007
git-svn-id: http://skia.googlecode.com/svn/trunk@13570 2bbb7eff-a529-9590-31e7-b0007b416f81
This change makes kSkipTiled_Flag also skip --tileGrid and --rtree.
All GMs which were passing kSkipTiled_Flag before were also passing
kSkipPicture_Flag, which also skips tilegrid and rtree, so this should
have no effect on them, but provides a smaller hammer for GMs which
still want to test picture playback, but not tiling.
The exception is magnifier, which was passing only kSkipTiled_Flag,
but magnifier is an odd beast and not web-exposed, so I'm not worried
about reducing its coverage slightly.
R=scroggo@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/165723009
git-svn-id: http://skia.googlecode.com/svn/trunk@13514 2bbb7eff-a529-9590-31e7-b0007b416f81
SkResizeImageFilter resizes all the pixels from its input (subject to
the input's crop rect), but the offset to be applied was incorrect.
It should take the CTM into account, so that the origin of the resize is
the world space origin, unaffected by whatever clipping is applied.
New GM imageresizetiled exercises the behaviour under
impl-side-painting-like conditions, and existing GMs now have resize
cases added.
R=reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/168283006
git-svn-id: http://skia.googlecode.com/svn/trunk@13506 2bbb7eff-a529-9590-31e7-b0007b416f81
