This implementation improves performance of SkMutex acquire / release pair from 42ns -> 13 ns.
SkSharedMutex and SkSpinlock have the same performance.
It also removes specialized windows and linux/mac code.
BUG=skia:
Review URL: https://codereview.chromium.org/1359733002
SkBitmapRegionDecoderInterface provides an interface
for multiple implementations of Android's
BitmapRegionDecoder.
We already have correctness tests in DM that will enable us
to compare the quality of our various BRD implementations.
We also need these performance tests to compare the speed
of our various implementations.
BUG=skia:4357
Review URL: https://codereview.chromium.org/1344993003
Reason for revert:
Failing ImageNewShaderTest on both Android (Tegra3 GPU) and iOS bots.
e.g.
/Users/chrome-bot/buildbot/skiabot-ipad4-000/build/slave/workdir/build/skia/tests/
ImageNewShaderTest.cpp:24 0 == memcmp(bm1.getPixels(), bm2.getPixels(), bm1.getSize())
ImageNewShaderTest.cpp:95 0xFFFF0000 == bmt.getColor(0, y)
ImageNewShaderTest.cpp:98 0xFFDEDEDE == bmt.getColor(x, y)
ImageNewShaderTest.cpp:98 0xFFDEDEDE == bmt.getColor(x, y)
ImageNewShaderTest.cpp:98 0xFFDEDEDE == bmt.getColor(x, y)
ImageNewShaderTest.cpp:98 0xFFDEDEDE == bmt.getColor(x, y)
ImageNewShaderTest.cpp:95 0xFFFF0000 == bmt.getColor(0, y)
...
Original issue's description:
> add ImageShader, sharing code with its Bitmap cousin
>
> This is done by having abstracted the BitmapShaderContext to take a BitmapProvider, instead of just a bitmap. This allows us to share all of that code between SkBitmap and SkImage, since both are valid providers.
>
> It also means that we can simplify SkImage_Base to not need a virtual for onNewShader, since ALL images can uniformly be turned into a shader now.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/0b93e3149d2cb30860c51f9f3204ae811d9a97caTBR=fmalita@chromium.org,bsalomon@google.com,robertphillips@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1355863002
This is done by having abstracted the BitmapShaderContext to take a BitmapProvider, instead of just a bitmap. This allows us to share all of that code between SkBitmap and SkImage, since both are valid providers.
It also means that we can simplify SkImage_Base to not need a virtual for onNewShader, since ALL images can uniformly be turned into a shader now.
BUG=skia:
Review URL: https://codereview.chromium.org/1342113002
The new FP is used to implement SkXM::Mode color filters and SkXM::Mode image filters. Also, these now support all advanced SkXM::Mode xfermodes.
Review URL: https://codereview.chromium.org/1334293003
Adds an entry point to GrContext to allow enumeration and tracing of GPU resources
via the newly added SkTraceMemoryDump.
Plan is for Chrome to call this on each of its GrContexts.
Dumps both the total size of GPU resources, as well as the total purgeable size.
BUG=526261
Review URL: https://codereview.chromium.org/1313743002
This makes the blurcircles bench go from ~33us to ~8us on Windows desktop.
It will require layout test suppressions
Review URL: https://codereview.chromium.org/1311583005
Blink is migrating away from SkBitmaps, so we need an SkImage-based
SkImageFilter source. This is pretty much a 1-1 equivalent of
SkBitmapSource.
To avoid duplication, relocate the SkImage deserialization logic
from SkPictureData to SkReadBuffer.
R=reed@google.com,robertphillips@google.com,senorblanco@chromium.org
Review URL: https://codereview.chromium.org/1343703005
Possible follow-up changes to consider
1. Roll SkImage_Raster and _Gpu into _Generator, where the generator (or cacherator) is backed by a pre-existing texture or raster.
2. Evolve SkImageUsageType into a verb requiring stretching, and have the caller (common code) digest the caps() and usage, so that subclasses are just told what to do (stretch or not)
3. Common code/utility to convert an unstretched texture into a stretch one (and cache it) if the generator can only make an unstretched one.
BUG=skia:
Review URL: https://codereview.chromium.org/1282363002
To match Chrome, make sure we've disabled thread-safe statics, RTTI, and exceptions. Linux needed -fno-threadsafe-statics, Mac needed all three.
Nothing important triggered this CL. I just got confused when I saw exception handling (calls to delete, stack unwinding) in some generated code on my laptop.
BUG=skia:
Review URL: https://codereview.chromium.org/1323533003
The newly created VisualLightweightBenchModule is just the old VisualBench.cpp, but gutted to only include timing code.
Future CLs will harden this abstraction, but for this CL the module owns a backpointer to VisualBench.cpp for a couple of calls.
BUG=skia:
Review URL: https://codereview.chromium.org/1304083007
The million SKPs generated require >5T of storage. A good deal
of that are copies of system fonts.
Chrome built with
#DEFINE SK_WHITELIST_SERIALIZED_TYPEFACES
will omit the font data if the font matches a precomputed
checksum.
The captured SKP prepends sk_ to the names of fonts that
have their data omitted. The SKP consumer can either add
renamed fonts from the recording machine, or add
gDeserializeTypefaceDelegate = WhitelistDeserializeTypeface;
which strips the sk_ prefix when deserializing typefaces.
whitelist_typefaces --check
Computes the checksums of fallback
fonts and returns 0 if the checksums match the checked-in
file SkWhitelistChecksum.cpp.
whitelist_typefaces --generate
Writes an updated version of SkWhitelistChecksum.cpp.
(Added Mike since this modifies a public header)
R=bungeman@google.com,rmistry@google.com,reed@google.com
Review URL: https://codereview.chromium.org/1317913005
