Like the other change, it makes SkAlignN(x) macros work for pointers, and makes the macros themselves just syntax sugar for SkAlign<N>(x). We can still decide if we want to sed away the macros independently.
This just does it in a somewhat less repetitive way, and adds some tests.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2368293002
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2368293002
This comes from the Skia fuzzer where it is inverting the RRect's rect which causes trouble down the line.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2591
Change-Id: I5c34105a47369492d2df99d39a4e29116060ad37
Reviewed-on: https://skia-review.googlesource.com/2591
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
For now, this is just the color space (of the original
requesting device). This is used when constructing
intermediate rendering surfaces, so that we ensure we
land in a surface that's similar/compatible to the
final consumer of the DAG's output.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2357273002
Review-Url: https://codereview.chromium.org/2357273002
Chromium needs to be able to set up their build such that the globals
continue existing but the SkFontMgr::Factory can be defined separately.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2346333002
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2346333002
skpbench is a benchmarking suite for skps that aims to generate 100%
repeatable results. The initial commit consists of three parts:
skpbench
A minimalist program whose sole purpose is to open an skp file,
benchmark it on a single config, and exit. No tiling, looping, or
other fanciness is used; it just draws the skp whole into a size-
matched render target and syncs the GPU after each draw.
Limiting the entire process to a single config/skp pair helps to keep
the results repeatable.
skpbench.py
A wrapper to execute the skpbench binary with various configs and skps.
It also monitors the output in order to filter out and re-run results
with an unacceptable stddev.
In the future this script will lock down and monitor clocks and
temperatures.
parseskpbench.py
A utility for parsing skpbench output into a spreadsheet.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2341823002
Review-Url: https://codereview.chromium.org/2341823002
Reason for revert:
Hitting an assert
Original issue's description:
> Support Float32 output from SkColorSpaceXform
>
> * Adds Float32 support to SkColorSpaceXform
> * Changes API to allows clients to ask for F32, updates clients to
> new API
> * Adds Sk4f_load4 and Sk4f_store4 to SkNx
> * Make use of new xform in SkGr.cpp
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339233003
> CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/43d6651111374b5d1e4ddd9030dcf079b448ec47TBR=brianosman@google.com,mtklein@google.com,scroggo@google.com,mtklein@chromium.org,bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2347473007
* Adds Float32 support to SkColorSpaceXform
* Changes API to allows clients to ask for F32, updates clients to
new API
* Adds Sk4f_load4 and Sk4f_store4 to SkNx
* Make use of new xform in SkGr.cpp
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339233003
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2339233003
This is a step towards using SkCodec in Chromium, where progressive
decoding is necessary.
Switch from using png_read_row (which expects all the data to be
available) to png_process_data, which uses callbacks when rows are
available.
Create a new API for SkCodec, which supports progressive decoding and
scanline decoding. Future changes will switch the other clients off of
startScanlineDecode and get/skip-Scanlines to the new API.
Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
updateCurrScanline(), which was only used by the old implementation for
interlaced PNG.
DMSrcSink:
- In CodecSrc::kScanline_Mode, use the new method for scanline decoding
for the supported formats (just PNG and PNG-in-ICO for now).
fuzz.cpp:
- Remove reference to kNone_ScanlineOrder
SkCodec:
- Add new APIs:
- startIncrementalDecode
- incrementalDecode
- Remove kNone_SkScanlineOrder and updateCurrScanline()
- Set fDstInfo and fOptions in getPixels(). This may not be necessary
for all implementations, but it simplifies things for SkPngCodec.
SkPngCodec:
- Implement new APIs
- Switch from sk_read_fn/png_read_row etc to png_process_data
- Expand AutoCleanPng's role to decode the header and create the
SkPngCodec
- Make the interlaced PNG decoder report how many lines were
initialized during an incomplete decode
SkIcoCodec:
- Implement the new APIs; supported for PNG in ICO
SkSampledCodec:
- Call the new method for decoding scanlines, and fall back to the old
method if the new version is unimplemented
- Remove references to kNone_SkScanlineOrder
tests/CodecPartial:
- Add a test which decodes part of an image, then finishes the decode,
and compares it to the straightforward method
tests/CodecTest:
- Add a test which decodes all scanlines using the new method
- Repurpose the Codec_stripes test to decode using the new method in
sections rather than all at once
- In the method check(), add a parameter for whether the image supports
the new method of scanline decoding, and be explicit about whether an
image supports incomplete
- Test incomplete PNG decodes. We should have been doing it anyway for
non-interlaced (except for an image that is too small - one row), but
the new method supports interlaced incomplete as well
- Make test_invalid_parameters test the new method
- Add a test to ensure that it's safe to fall back to scanline decoding without
rewinding
BUG=skia:4211
The new version was generally faster than the old version (but not significantly so).
Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
Review-Url: https://codereview.chromium.org/1997703003
The SkFontData type is not exposed externally, so any method which uses
it can be updated to use smart pointers without affecting external
users. Updating this first will make updating the public API much
easier.
This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
appears that no one outside Skia is currently using SkStream::NewfromFile
so this is a good time to update it as well.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
Committed: https://skia.googlesource.com/skia/+/d8c2476a8b1e1e1a1771b17e8dd4db8645914f8c
Review-Url: https://codereview.chromium.org/2339273002
For now, we still only have the SkColor factory, but the Descriptor can
now carry either an SkColor or SkColor4f specified gradient. Base class
constructor automatically populates both forms of color, so that legacy
raster backend will continue to work, and new backend work can operate
directly from the float4 version.
On the GPU side, we have similar logic, but GrGradientEffect only
keeps one version of colors around: SkColor if the destination is
legacy, and SkColor4f (with an optional gamut xform) if the destination
is gamma correct. The 4f colors are already linear, and we gamut xform
them in setData, so gradients are now fully color-correct in sRGB and
F16 modes...
... unless there are more than three stops. Then we use a texture, and
that code path isn't handled yet. We have a few choices here (do we
use an 8-bit sRGB atlas, or just always use F16 linear atlas so we can
share it among both sRGB and wide-gamut rendering). In any case, I'd
like to defer that to a second CL.
This change does fix the non-texture gradients in the gamut GM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2337313002
Review-Url: https://codereview.chromium.org/2337313002
Reason for revert:
Killing Mac
Original issue's description:
> SkFontData to use smart pointers.
>
> The SkFontData type is not exposed externally, so any method which uses
> it can be updated to use smart pointers without affecting external
> users. Updating this first will make updating the public API much
> easier.
>
> This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
> std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
> appears that no one outside Skia is currently using SkStream::NewfromFile
> so this is a good time to update it as well.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
>
> Committed: https://skia.googlesource.com/skia/+/d8c2476a8b1e1e1a1771b17e8dd4db8645914f8cTBR=mtklein@chromium.org,halcanary@google.com,mtklein@google.com,reed@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2343933002
The SkFontData type is not exposed externally, so any method which uses
it can be updated to use smart pointers without affecting external
users. Updating this first will make updating the public API much
easier.
This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
appears that no one outside Skia is currently using SkStream::NewfromFile
so this is a good time to update it as well.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
Review-Url: https://codereview.chromium.org/2339273002
1. Remove special premul handling from gamut xform code
Alpha is a constant, so the gamut transformation results remain unchanged
(it distributes across the linear matrix multiply).
2. Use SkMatrix44 rather than array of floats
Preserves semantic intention, and makes upcoming code (where we transform
colors on the CPU by that matrix) simpler.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2329553002
Review-Url: https://codereview.chromium.org/2329553002
We were effectively storing the transpose, which made all of our
operations on individual colors, and our concatenation of matrices
awkward and backwards.
I'm planning to push this further into Ganesh, where I had incorrectly
adjusted to the previous layout, treating colors as row vectors in the
shaders.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2324843003
Review-Url: https://codereview.chromium.org/2324843003
Consolidates all flush actions into GrDrawingManager and makes GrContext::flush a passthrough.
Removes the unused and untested discard flush variation.
Replaces the indirect overbudget callback mechanism of GrResourceCache with a flag set by resource cache when it wants to flush that is checked after each draw by GrDrawContext.
Modifies GrResourceCache::notifyFlushOccurred() to take a param indicating whether it triggered the
flush that just occurred.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2307053002
Committed: https://skia.googlesource.com/skia/+/1dbb207babecdae8f1f74ed9d9900c73064df744
Review-Url: https://codereview.chromium.org/2307053002
New helper functions inject the necessary shader
function. Texture lookup functions can now insert
the gamut xform at the appropriate place, too.
As written, could be used to transform non-texture
colors (e.g. vertex colors) as well.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2180803005
Review-Url: https://codereview.chromium.org/2180803005
Reason for revert:
Causing assertions on bots
Original issue's description:
> Restructure flushing relationship between GrContext, GrDrawingManager, and GrResourceCache.
>
> Consolidates all flush actions into GrDrawingManager and makes GrContext::flush a passthrough.
>
> Removes the unused and untested discard flush variation.
>
> Replaces the indirect overbudget callback mechanism of GrResourceCache with a flag set by resource cache when it wants to flush that is checked after each draw by GrDrawContext.
>
> Modifies GrResourceCache::notifyFlushOccurred() to take a param indicating whether it triggered the
> flush that just occurred.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2307053002
>
> Committed: https://skia.googlesource.com/skia/+/1dbb207babecdae8f1f74ed9d9900c73064df744TBR=robertphillips@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2312123003
Consolidates all flush actions into GrDrawingManager and makes GrContext::flush a passthrough.
Removes the unused and untested discard flush variation.
Replaces the indirect overbudget callback mechanism of GrResourceCache with a flag set by resource cache when it wants to flush that is checked after each draw by GrDrawContext.
Modifies GrResourceCache::notifyFlushOccurred() to take a param indicating whether it triggered the
flush that just occurred.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2307053002
Review-Url: https://codereview.chromium.org/2307053002
HWUI skips transparent rects when drawing.
When skia draws using bilerp, we will blend
transparent rects with neighboring rects and might
draw a bit of a smudge.
This CL adds the option to skip rects, allowing us
to have compatible behavior with the framework.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2305433002
Review-Url: https://codereview.chromium.org/2305433002
Instead of mapping invaid glyphIDs to zero or maxGlyphID,
don't draw them at all.
Validate glyphs when glyph is written, not ahead of time.
Don't allocate array to copy user-provided glyphs.
Easy early exit from SkPDFDevice::internalDrawText()
GlyphPositioner::flush() called ~GlyphPositioner()
SkScopeExit class now exists.
Assume SkTypeface* pointers are now never null in more
places.
precalculate alignmentFactor to clean up code.
SkPDFDevice::updateFont must be called with validated
glyphID. Skip bad glyphs to make this true.
SkPDFDevice::updateFont always succeeds.
SkPDFFont::GetFontResource always succeeds (preconditions are
asserted). If GetMetrics fails, don't call GetFontResource.
SkPDFFont::glyphsToPDFFontEncodingCount() becomes
SkPDFFont::countStretch() and is inlined.
SkPDFFont::glyphsToPDFFontEncoding now works one Glyph at a
time and is inlined.
SkPDFFont::noteGlyphUsage() operates one glyph at a time.
Add SkScopeExit.h; also a unit test for it.
SkPostConfig: Fix SK_UNUSED for Win32.
No public API changes.
TBR=reed@google.com
BUG=625995
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2278703002
Review-Url: https://codereview.chromium.org/2278703002
When Skia is built into the Android framework,
SK_SFNTLY_SUBSETTER="sample/chromium/font_subsetter.h".
This sets the same value for Skia's test framework
I will eventually move away from the
#include PREPROCESSOR_DEFINE
trick, which does not work everywhere.
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2274223002
Our tools use third-party libraries pretty freely, some of which may not
be available in other GN environments (e.g. Fuchsia). Most can also not
function when Skia is built as a shared library.
fiddle stands alone as the exception to both those points: it depends on
only Skia, and works fine with both a shared or static library.
So guard everything but fiddle with this flag skia_enable_tools, disabled
when we're building for Fuchsia or when we're build a shared library.
This CL has a couple of little tweaks to Fiddle to keep it working:
- divorce it from :tool_utils, instead just building SkForceLinking.cpp itself;
- fix up a buggy rebase_path() that was accidentally working when we depended
on :tool_utils;
- drop test_only: it now only requires production-code dependencies.
The SkImageEncoder Create* methods need to be SK_API if we want SkForceLinking
to work across .so's. Without this, SkForceLinking needs to be part of Skia; it
can't be part of the application using Skia.
The rest is mostly just a re-indent under if (skia_enable_tools),
courtesy of gn format.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2273823003
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2273823003
Reason for revert:
speculative
Original issue's description:
> Fast path translate() in SkCanvas and SkLiteDL.
>
> This adds didTranslate() so that SkLiteDL (and other canvas recorders)
> can record the translate rather than the full concat.
>
> It also adds a case to SkMatrix::preTranslate() to fast path
> translate x translate -> translate (i.e. +=).
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2255283002
>
> Committed: https://skia.googlesource.com/skia/+/5fa47f4fd13b3158de4599414c86d17649c2dd1cTBR=herb@google.com,reed@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2264433002
This adds didTranslate() so that SkLiteDL (and other canvas recorders)
can record the translate rather than the full concat.
It also adds a case to SkMatrix::preTranslate() to fast path
translate x translate -> translate (i.e. +=).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2255283002
Review-Url: https://codereview.chromium.org/2255283002
Keep isOpaque as a convenience method -- many places really only need to
know that for optimization purposes (SrcOver -> Src, etc...).
In all the places where we pull data back out or convert to another
object and need to supply an SkImageInfo, we can avoid losing information
about premulness.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2250663002
Review-Url: https://codereview.chromium.org/2250663002
SkPDFFont:
* inline some one-line methdods.
- SkPDFFont::typeface()
- SkPDFFont::fontInfo()
- SkPDFFont::firstGlyphID()
- SkPDFFont::lastGlyphID()
- SkPDFFont::getFontDescriptor()
* de-virtualize some methods:
- SkPDFFont::getType()
- SkPDFFont::multiByteGlyphs()
* Constructor takes more arguments:
fontType, multiByteGlyphs
* re-order fields (pointers before shorts)
* use sk_sp<T> more, T* less
SkAdvancedTypefaceMetrics:
* SkAdvancedTypefaceMetrics::fFont now a uint8_t
* other enumes are sized.
* SkAdvancedTypefaceMetrics::fStyle now big enough.
* remove use of SkTBitOr, replaced with fancy templates
No public API changes.
TBR=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2246903002
Review-Url: https://codereview.chromium.org/2246903002
GrAppliedClip was about at its limit for how many "make" functions it
could have. Window rectangles would push it over the edge. This change
makes it so GrDrawTarget supplies the original draw bounds to the
constructor, and then GrClip adds the various required clipping
techniques.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2246113002
Review-Url: https://codereview.chromium.org/2246113002
Impl Overview
(1) Keep the device clip bounds up to date. This
requires minimal additional work in a few places
throughout canvas.
(2) Keep track of if the ctm isScaleTranslate. Yes,
there's a function that does this, but it's slow
to call.
(3) Perform the src->device transform in quick reject,
then check intersection/nan.
Other Notes:
(1) NaN and intersection checks are performed
simultaneously.
(2) We no longer quick reject infinity.
(3) Affine and perspective are both handled in the slow
case.
(4) SkRasterClip::isEmpty() is handled by the intersection
check.
Performance on Nexus 6P:
93.2ms -> 59.8ms
Overall Android Jank Tests Performance Impact:
Should gain us a ms or two on some tests.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2225393002
Committed: https://skia.googlesource.com/skia/+/d22a817ff57986407facd16af36320fc86ce02da
Review-Url: https://codereview.chromium.org/2225393002
Impl Overview
(1) Keep the device clip bounds up to date. This
requires minimal additional work in a few places
throughout canvas.
(2) Keep track of if the ctm isScaleTranslate. Yes,
there's a function that does this, but it's slow
to call.
(3) Perform the src->device transform in quick reject,
then check intersection/nan.
Other Notes:
(1) NaN and intersection checks are performed
simultaneously.
(2) We no longer quick reject infinity.
(3) Affine and perspective are both handled in the slow
case.
(4) SkRasterClip::isEmpty() is handled by the intersection
check.
Performance on Nexus 6P:
93.2ms -> 59.8ms
Overall Android Jank Tests Performance Impact:
Should gain us a ms or two on some tests.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2225393002
Review-Url: https://codereview.chromium.org/2225393002
sk_fontmgr_create_default used to exist before SkFontMgr::RefDefault
could do the job better. There are no actual implementations for this
function, so SkFontMgr should no longer be friends with it.
TBR=reed
Removes a deceased friend.
Review-Url: https://codereview.chromium.org/2232963002
Reading extern values meant these couldn't be compile-time constants.
math.h has INFINITY, which is macro that is supposed to expand to float +inf.
On MSVC it seems it's natively a double, so we cast just to make sure.
There's nan(const char*) in math.h for NaN too, but I don't trust that
to be compile-time evaluated. So instead, we keep reinterpreting a bit pattern.
I did try to write
static constexpr float float_nan() { ... }
and completely failed. constexpr seems a bit too restrictive in C++11 to make
it work, but Clang kept telling me, you'll be able to do this with C++14.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2233853002
Review-Url: https://codereview.chromium.org/2233853002
Reason for revert:
Erg - dumb bug
Original issue's description:
> Create blurred RRect mask on GPU (rather than uploading it)
>
> This CL doesn't try to resolve any of the larger issues. It just moves the computation of the blurred RRect to the gpu and sets up to start using vertex attributes for a nine patch draw (i.e., returning the texture coordinates)
>
> All blurred rrects using the "analytic" path will change slightly with this CL.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222083004
>
> Committed: https://skia.googlesource.com/skia/+/75ccdc77a70ec2083141bf9ba98eb2f01ece2479TBR=bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2236493002
This CL doesn't try to resolve any of the larger issues. It just moves the computation of the blurred RRect to the gpu and sets up to start using vertex attributes for a nine patch draw (i.e., returning the texture coordinates)
All blurred rrects using the "analytic" path will change slightly with this CL.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222083004
Review-Url: https://codereview.chromium.org/2222083004
SkPDFFont:
- SkPDFType1Font::populate() encode advances correctly.
- break out logically independent code into new files:
* SkPDFConvertType1FontStream
* SkPDFMakeToUnicodeCmap
SkPDFFont.cpp is now 380 lines smaller.
Expose `SkPDFAppendCmapSections()` for testing.
SkPDFFontImpl.h
- Fold into SkPDFFont.
SkPDFConvertType1FontStream:
- Now assume given a SkStreamAsset
SkPDFFont:
- AdvanceMetric now hidden in a anonymous namespace.
No public API changes.
TBR=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2221163002
Review-Url: https://codereview.chromium.org/2221163002
These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.
Destruction can be a little more direct, and if nothing else,
sizeof(T) will get a little smaller by dropping the vptr.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
Review-Url: https://codereview.chromium.org/2232433002
About 9x faster than Murmur3 for long inputs.
Most of this is a mechanical change from SkChecksum::Murmur3(...) to SkOpts::hash(...).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2208903002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2208903002
The code protected by this flag is no longer used. Remove the flag and
code. This also removes SK_SUPPORT_LEGACY_TYPEFACE_PTR from Android, as
it is no longer needed.
TBR=reed
Only removes already guarded API.
Review-Url: https://codereview.chromium.org/2223933002
SkLiteRecorder, a new SkCanvas, fills out SkLiteDL, a new SkDrawable.
This SkDrawable is a display list similar to SkRecord and SkBigPicture / SkRecordedDrawable, but with a few new design points inspired by Android and slimming paint:
1) SkLiteDL is structured as one big contiguous array rather than the two layer structure of SkRecord. This trades away flexibility and large-op-count performance for better data locality for small to medium size pictures.
2) We keep a global freelist of SkLiteDLs, both reusing the SkLiteDL struct itself and its contiguous byte array. This keeps the expected number of mallocs per display list allocation <1 (really, ~0) for cyclical use cases.
These two together mean recording is faster. Measuring against the code we use at head, SkLiteRecorder trends about ~3x faster across various size pictures, matching speed at 0 draws and beating the special-case 1-draw pictures we have today. (I.e. we won't need those special case implementations anymore, because they're slower than this new generic code.) This new strategy records 10 drawRects() in about the same time the old strategy took for 2.
This strategy stays the winner until at least 500 drawRect()s on my laptop, where I stopped checking.
A simpler alternative to freelisting is also possible (but not implemented here), where we allow the client to manually reset() an SkLiteDL for reuse when its refcnt is 1. That's essentially what we're doing with the freelist, except tracking what's available for reuse globally instead of making the client do it.
This code is not fully capable yet, but most of the key design points are there. The internal structure of SkLiteDL is the area I expect to be most volatile (anything involving Op), but its interface and the whole of SkLiteRecorder ought to be just about done.
You can run nanobench --match picture_overhead as a demo. Everything it exercises is fully fleshed out, so what it tests is an apples-to-apples comparison as far as recording costs go. I have not yet compared playback performance.
It should be simple to wrap this into an SkPicture subclass if we want.
I won't start proposing we replace anything old with anything new quite yet until I have more ducks in a row, but this does look pretty promising (similar to the SkRecord over old SkPicture change a couple years ago) and I'd like to land, experiment, iterate, especially with an eye toward Android.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
Review-Url: https://codereview.chromium.org/2213333002
In Firefox, we use SkCanvas::saveLayer in combination with a backdrop that initializes the layer to the background. When this is blended back onto background using transparency, where the source and destination pixel colors are the same, the resulting color after the blend is not preserved due to the lost precision mentioned above. In cases where this operation is repeatedly performed, this causes substantially noticeable differences in color as evidenced in this downstream Firefox bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1200684
In the test-case in the downstream report, essentially it does blend(src=0xFF2E3338, dst=0xFF2E3338, scale=217), which gives the result 0xFF2E3237, while we would expect to get back 0xFF2E3338.
This problem goes away if the blend is instead reformulated to effectively do (src*src_scale + dst*dst_scale)>>8, which keeps the intermediate precision during the addition before shifting it off.
This modifies the blending operations thusly. The performance should remain mostly unchanged, or possibly improve slightly, so there should be no real downside to doing this, with the benefit of making the results more accurate. Without this, it is currently unsafe for Firefox to blend a layer back onto itself that was initialized with a copy of its background.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2097883002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
[mtklein adds...]
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2097883002
Change SkDataTable::NewXXX to SkDataTable::MakeXXX and return sk_sp.
This updates users of SkDataTable to sk_sp as well.
There do not appear to be any external users of these methods.
Review-Url: https://codereview.chromium.org/2211143002
Lessons learned
1. ImageShader (correctly) always compresses (typically via PNG) during serialization. This has the surprise results of
- if the image was marked opaque, but has some non-opaque pixels (i.e. bug in blitter or caller), then compressing may "fix" those pixels, making the deserialized version draw differently. bug filed.
- 565 compressess/decompresses to 8888 (at least on Mac), which draws differently (esp. under some filters). bug filed.
2. BitmapShader did not enforce a copy for mutable bitmaps, but ImageShader does (since it creates an Image). Thus the former would see subsequent changes to the pixels after shader creation, while the latter does not, hence the change to the BlitRow test to avoid this modify-after-create pattern. I sure hope this prev. behavior was a bug/undefined-behavior, since this CL changes that.
BUG=skia:5595
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2195893002
Review-Url: https://codereview.chromium.org/2195893002
