use a SkSpinlock instead of SkMutex. This results in significant
performance increase for mpd in nanobench.
BUG=skia:
Review URL: https://codereview.chromium.org/1210143004
The proportion of time spent doing useful work is well over 99% in acquire(),
so outlining it doesn't hurt speed at all, and makes it much easier to pick out
on a profile.
It'd be about 50/50 work/overhead if we outlined the extremely-cheap release().
I also tried outlining some SkRefCnt methods with similar mixed results.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1212253013
Follow up to the split between SkImageGenerator and SkCodec. Now that
SkCodec does not inherit from SkImageGenerator, SkImageGenerator no
longer needs Options or Result, which were added for SkCodec. Remove
them, but keep them behind a flag, since Chromium has its own
subclasses of SkImageGenerator which assume the old signature for
onGetPixels.
Review URL: https://codereview.chromium.org/1226023003
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
This is currently only works on Linux hosts because we have checked
in a binary and does not work on Mac hosts. We are disabling until
we find a suitable solution.
BUG=skia:4028
Review URL: https://codereview.chromium.org/1228823006
Reason for revert:
Compilation failures:
../../../../../samplecode/SampleLighting.cpp:13:18: fatal error: SkGr.h: No such file or directory
Original issue's description:
> Add normal map sample
>
> This adds an example of an SkShader that does normal
> mapping. It has a single directional light and an
> ambient light.
>
> Committed: https://skia.googlesource.com/skia/+/8e0da72ba890de395c9946ec6639c9e1e7b16027TBR=reed@google.com,bsalomon@google.com,jvanverth@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1230603002
This adds an example of an SkShader that does normal
mapping. It has a single directional light and an
ambient light.
Review URL: https://codereview.chromium.org/1212813009
This tickles a warning in Clang:
reference cannot be bound to dereferenced null pointer in well-defined
C++ code; pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
BUG=none
Review URL: https://codereview.chromium.org/1225053003
Attempting to instantiate image decoders at this stage introduces
embedder dependencies.
Instead, we can just let callers set up any needed generators on the
bitmap.
R=reed@google.com
Review URL: https://codereview.chromium.org/1218663012
These wrappers are approxiately 56K in size and are the recommened
way to use Gradle. It also ensures that developers wanting to
build the app don't need install an additional dependency.
Review URL: https://codereview.chromium.org/1227723002
DEPS:
Update to pull v0.4.3 of libwebp from upstream
gyp/libwebp.gyp:
Add new files, as referenced by the gyp file used by Chromium.
resource/tests:
Add regression tests for particular images.
BUG=skia:3442
BUG=skia:3315
BUG=skia:3429
Review URL: https://codereview.chromium.org/1178013008
Tested by running on skps/sp_desk_nytimes.skp.
The output .skp had no nested draw picture calls, and the files were both 9.3M.
BUG=skia:
Review URL: https://codereview.chromium.org/1221303020
We name our .pngs by pixel hashes for gold. For 8888 images, we're hashing
SkPMColors, which have platform-dependent order: BGRA on Linux and Windows,
RGBA otherwise. This means we can end up with pixel-identical pngs with
different hashes, which is confusing.
This CL standardizes on RGBA for 8888 configs, arbitrarily chosen so that
Android ends up a no-op. Long-term, this should eliminate most of the
0-pixel-diff problems we see on gold.skia.org. There are other ways to end up
with the same .png from different SkBitmaps (think, red 565 square vs. red 8888
square) but they're rather less common / likely.
This will temporarily create a giant 0-pixel-diff problem on gold.skia.org.
Any Linux or Windows images which are not already pixel-identical to a Mac or
Android image should show up as untriaged hashes that are pixel-identical to
their version just before landing (we're only changing the hash, not the .png).
This means anything vaguely platform dependent (fonts, GPUs) will probably show
up as needing a triage but with a zero diff from a previous image.
If this goes well, we might do the same for 565. Just want to leave them out
for now to cut down on the triaging I need to do in one go.
BUG=skia:
Review URL: https://codereview.chromium.org/1226933005
This tickles a warning in Clang:
reference cannot be bound to dereferenced null pointer in well-defined
C++ code; pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
BUG=none
Review URL: https://codereview.chromium.org/1220113003
