Mostly this is about ergonomics, making it easier to do good operations and hard / impossible to do bad ones.
- SkAlpha / SkPMColor constructors become static factories.
- Remove div255TruncNarrow(), rename div255RoundNarrow() to div255(). In practice we always want to round, and the narrowing to 8-bit is contextually obvious.
- Rename fastMulDiv255Round() approxMulDiv255() to stress it's approximate-ness over its speed. Drop Round for the same reason as above... we should always round.
- Add operator overloads so we don't have to keep throwing in seemingly-random Sk4px() or Sk4px::Wide() casts.
- use operator*() for 8-bit x 8-bit -> 16-bit math. It's always what we want, and there's generally no 8x8->8 alternative.
- MapFoo can take a const Func&. Don't think it makes a big difference, but nice to do.
BUG=skia:
Review URL: https://codereview.chromium.org/1202013002
This CL starts the process of pushing kLegacyFontHost_InitType-type SkSurfaceProps up the call stack and out of Skia. It:
Gets rid of the default SkBaseDevice ctor. This means everyone has to always hand an explicit SkSurfaceProps to it.
It makes public the SkBitmapDevice creation methods that require SkSurfaceProps.
Removes (in Skia's code base) all SkBitmapDevice ctor calls w/o SkSurfaceProps.
Makes the "recording" canvases (e.g., pdf, svg, xps) explicitly not use kLegacyFontHost_InitType.
Replicates the creating canvas/device's flags on saveLayer devices
BUG=skia:3934
Review URL: https://codereview.chromium.org/1204433002
The regression occurred when we dropped the maximum DF size from 192
to 162, which meant that any glyph > 324 ended up being rendered as paths
rather than the previous > 384. This pushes the threshold for
rendering paths up to 384. Quality looks fine on high-res devices
which is why this is restricted to Android-only (low-res Android devices
should only rarely have text that large).
BUG=chromium:467569
Committed: https://skia.googlesource.com/skia/+/932d413e69845989fadaecf5bcb8686ec8c05032
Review URL: https://codereview.chromium.org/1183053005
sk_inv_determinant has a guard that the determinant can't get too big so this CL only checks if the determinant gets too small.
BUG=492263
Review URL: https://codereview.chromium.org/1188433011
The SkFaceRec class is some data which needs to remain alive for the
life of an FT_Face. ref_ft_face returns SkFaceRec, but confusingly
unref_ft_face takes an FT_Face. Since no one was using the SkFaceRec
for anything other than accessing the FT_Face, have ref_ft_face
return FT_Face instead and remove the unused SkFaceRec pointer from
the scaler context.
Review URL: https://codereview.chromium.org/1180223005
The regression occurred when we dropped the maximum DF size from 192
to 162, which meant that any glyph > 324 ended up being rendered as paths
rather than the previous > 384. This pushes the threshold for
rendering paths up to 384. Quality looks fine on high-res devices
which is why this is restricted to Android-only (low-res Android devices
should only rarely have text that large).
BUG=chromium:467569
Review URL: https://codereview.chromium.org/1183053005
Based on SkImageDecoder_libwebp.
TODO:
Support YUV? (Longer term - may influence our API for SkImageGenerator)
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044433002
Updates GrGLProgram to tell the gpu object which textures it wants
bound, instead of calling bindTexture directly. This begins to break
its dependence on the specific GrGLGpu object.
BUG=skia:
Review URL: https://codereview.chromium.org/1192463003
The intent was to define FT_HAS_COLOR when building with a pre
2.5.1 version of FreeType for forward compatibility. However,
the definition here is wrong and also never used.
Review URL: https://codereview.chromium.org/1178943009
This file had one declaration in it which actually affected the
SkFontMgr and had nothing to do with typefaces specifically. As a
result, the declaration was moved to SkFontMgr_android.h. Now that
the users have been updated, remove this now unused file.
Review URL: https://codereview.chromium.org/1177173004
When calling SkRegion::writeToMemory(NULL), it should return the same
number of bytes that it writes when calling
SkRegion::writeToMemory(buffer). Add a test to confirm this.
BUG=b/21271229
Review URL: https://codereview.chromium.org/1188293002
This should be a drop-in replacement for most for-loops to make them run in parallel:
for (int i = 0; i < N; i++) { code... }
~~~>
sk_parallel_for(N, [&](int i) { code... });
This is just syntax sugar over SkTaskGroup to make this use case really easy to write.
There's no more overhead that we weren't already forced to add using an interface like batch(),
and no extra heap allocations.
I've replaced 3 uses of SkTaskGroup with sk_parallel_for:
1) My unit tests for SkOnce.
2) Cary's path fuzzer.
3) SkMultiPictureDraw.
Performance should be the same. Please compare left and right for readability. :)
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1184373003
Reason for revert:
Seeing some Nexus 4 perf regressions in individual tests in Chromium that may be due to this change. This doesn't appear to be the correct fix for the bug in any case.
Original issue's description:
> Bump up point where we switch to distance fields for large glyphs
>
> This is hopefully a temporary fix. It's unclear why distance fields
> are so much slower on the N4 (and N7).
>
> BUG=chromium:467569
>
> Committed: https://skia.googlesource.com/skia/+/0fce1fb02d93e66d42528f322f8aa4ca64ff0fb2TBR=joshualitt@google.com,bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:467569
Review URL: https://codereview.chromium.org/1178713005
