This CL refactors the location of the GrBufferAllocPools so they reside entirely inside the GrBatchTarget. This is in preparation for making them use scratch resources.
Review URL: https://codereview.chromium.org/1131553002
Motivation: PDF/A metadata will need the creation date embedded in it.
Also, GetDateTime returns local time in Win32. This now behaves the
same as on Unix systems.
BUG=skia:3110
Review URL: https://codereview.chromium.org/1109593002
Updates GrXferProcessor to read directly from the RT texture when
texture barriers are supported and it needs to know the dst color.
Also adds the notion of an Xfer barrier and uses it to issue texture
barriers when the XP will read the RT.
BUG=skia:
Review URL: https://codereview.chromium.org/1040303002
All but 17 extended tests work.
A helper function is privately added to SkPath.h to permit a test to modify a given point in a path.
BUG=skia:3588
Review URL: https://codereview.chromium.org/1107353004
Must have been we needed them to be weird (mutable, const setter) before.
It doesn't look like that's necessary now... we can just pass it to the
constructor.
BUG=skia:
Review URL: https://codereview.chromium.org/1112833003
The pointer of reference is always not-null. It causes >50k lines of warnning when chromium is compiled by clang.
Warning looks like
../../third_party/skia/include/core/SkRect.h:284:19: warning: 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]
do { if (&r) break; SkNO_RETURN_HINT(); SkDebugf_FileLine("../../third_party/skia/include/core/SkRect.h", 284, false, "%s:%d: failed assertion \"%s\"\n", "../../third_party/skia/include/core/SkRect.h", 284, "&r"); SkDebugf_FileLine("../../third_party/skia/include/core/SkRect.h", 284, true, "SK_CRASH"); } while (false);
Review URL: https://codereview.chromium.org/1111013002
Effectively all this does is future-proof any GLSL-specific code, as
GLSLCaps is just a typedef of GLCaps.
BUG=skia:
Review URL: https://codereview.chromium.org/1109863004
Reason for revert:
MIPS
Original issue's description:
> De-proc Color32
>
> Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
> which is no longer needed.
>
> Seems handy to have SkTypes include the relevant intrinsics when
> we know we've got them, but I'm not married to it.
>
> Locally this looks like a pointlessly small perf win, but I'm mostly
> keen to get all the code together.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72bTBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1108163002
Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
which is no longer needed.
Seems handy to have SkTypes include the relevant intrinsics when
we know we've got them, but I'm not married to it.
Locally this looks like a pointlessly small perf win, but I'm mostly
keen to get all the code together.
BUG=skia:
Review URL: https://codereview.chromium.org/1104183004
This may be a small help to slimming paint:
picture_overhead_draw 1.25us -> 1.22us 0.98x
picture_overhead_nodraw 318ns -> 276ns 0.87x
It certainly cannot hurt performance.
BUG=chromium:470553
TBR=reed@google.com
No public API changes.
Review URL: https://codereview.chromium.org/1098183003
This saves "up to" 22 bytes per SkPicture.
Due to alignment, this reduces sizeof(SkPicture):
- from 88 to 72 bytes on Linux x64
- from 68 to 48 bytes on Android
(with Chrome's build settings)
It also somewhat simplifies the GPU veto logic.
BUG=skia:
[mtklein] No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1060863004
Move line dashing logic from GrContext::drawPath to
GrDashLinePathRenderer. This makes it possible to let path renderers render arbitrary dashed paths.
End goal is to implement dashing in GrStencilAndCoverPathRenderer.
Review URL: https://codereview.chromium.org/1100073003
Adds an onGetBlendInfo method for GrXferProcessor subclasses to
override instead of overriding getBlendInfo directly. This gives the
base class a chance to initialize the struct with default values
before passing it on. As the BlendInfo struct grows, this will keep
things simple and less error prone.
BUG=skia:
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1049143002
Also adds glBlendEquation, which the extension interacts with, to the
core of GrGLInterface. Validation of this function is temporarily
disabled until Chrome hooks it up.
BUG=skia:
Review URL: https://codereview.chromium.org/1039693004
Chrome wants to call this more often, and it's quite slow today.
Seems like this could be clearer if SkPictureUtils::ApproxBytesUsed() were SkPicture::approxBytesUsed().
BUG=chromium:471873
Review URL: https://codereview.chromium.org/1090943004
SkFixedToDouble uses the decimal floating point string representation
of 1/(2^16) to provide a constant value. This value is exactly
representable by a double but the decimal constant currently used
does not map to this value.
This change modifies this constant to more decimal digits so that
the actual double value desired is created.
Review URL: https://codereview.chromium.org/1097473002
Currently there exist SkScalarPin and SkPin32, and in a future change
another version is desired. This change introduces SkTPin and changes
SkScalarPin and SkPin32 to use it.
Review URL: https://codereview.chromium.org/1090003002
The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this
is because of the reduced function-call-then-function-pointer-call overhead on
the N7, and additionally because it seems autovectorization beats our NEON code
for small N on the N9.
My desktop is unchanged, though that's probably because N=10 lies well within a
region where memset's performance is essentially constant: N=100 takes only
about 2x as long as N=1 and N=10, which perform nearly identically.
BUG=skia:
Review URL: https://codereview.chromium.org/1073863002
Instead of using a full-blown SkPaint to store run font info, use a
custom structure.
This saves 96 bytes / run on 64bit platforms.
R=reed@google.com,mtklein@google.com,joshualitt@google.com
Review URL: https://codereview.chromium.org/1070943002
This CL also adds a new parameter to SkBitmapSource which gives the user control of the filter quality.
BUG=472795
Review URL: https://codereview.chromium.org/1072603002
No diffs against head for DM --config 8888 gpu 2ndpic-8888 2ndpic-gpu.
picture_overhead_draw 1.62us -> 1.6us 0.99x
picture_overhead_nodraw 792ns -> 342ns 0.43x
tiles and serialization modes will also test this a bit.
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1067893002
If no one has read the picture's unique ID, there's no point invalidating it.
This is the same trick we pull with SkPixelRefs.
Before:
26M 1 1.49µs 1.6µs 1.77µs 6.25µs 42% picture_overhead_draw
13M 32 742ns 749ns 756ns 823ns 2% picture_overhead_nodraw
After:
26M 1 1.27µs 1.33µs 1.49µs 5.51µs 45% picture_overhead_draw
14M 43 677ns 680ns 681ns 701ns 1% picture_overhead_nodraw
BUG=skia:
Review URL: https://codereview.chromium.org/1061283002
- It's no longer needed to help the (2011?) transition to SkAutoTUnref.
- It prevents us from making classes that go in SkAutoTUnrefs final,
i.e. all ref-counted classes.
This had better not have been public API...
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1068443002
Add a virtual method on SkStream which will do a "peek" some bytes, so
that those bytes are read, but the next call to read will be
unaffected.
Implement peek for SkMemoryStream, where the implementation is simple
and obvious.
Implement peek on SkFrontBufferedStream.
Add tests.
Motivated by decoding streams which cannot be rewound.
TBR=reed@google.com
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044953002
This mirrors the behavior in onGetPixels, and allows the implementation
to share code for handling calls to rewindIfNeeded.
This also fixes a bug where getScanlineDecoder was calling
rewindIfNeeded and treating the result as a bool.
In SkPngCodec, factor out the code to call rewindIfNeeded, and call it
in both onGetPixels and onGetScanlineDecoder.
Update the test to include testing the scanline decoder. Rename "gen"
to "codec" now that it must be an SkCodec.
BUG=skia:3257
Depends on https://codereview.chromium.org/1048423003/ (DIFFERENT ISSUE).
Review URL: https://codereview.chromium.org/1050893002
The primary feature this delivers is SkNf and SkNd for arbitrary power-of-two N. Non-specialized types or types larger than 128 bits should now Just Work (and we can drop in a specialization to make them faster). Sk4s is now just a typedef for SkNf<4, SkScalar>; Sk4d is SkNf<4, double>, Sk2f SkNf<2, float>, etc.
This also makes implementing new specializations easier and more encapsulated. We're now using template specialization, which means the specialized versions don't have to leak out so much from SkNx_sse.h and SkNx_neon.h.
This design leaves us room to grow up, e.g to SkNf<8, SkScalar> == Sk8s, and to grown down too, to things like SkNi<8, uint16_t> == Sk8h.
To simplify things, I've stripped away most APIs (swizzles, casts, reinterpret_casts) that no one's using yet. I will happily add them back if they seem useful.
You shouldn't feel bad about using any of the typedef Sk4s, Sk4f, Sk4d, Sk2s, Sk2f, Sk2d, Sk4i, etc. Here's how you should feel:
- Sk4f, Sk4s, Sk2d: feel awesome
- Sk2f, Sk2s, Sk4d: feel pretty good
No public API changes.
TBR=reed@google.com
BUG=skia:3592
Review URL: https://codereview.chromium.org/1048593002
Need to land SK_SUPPORT_LEGACY_SCALAR_MAPPOINTS in chrome to suppress Affine
version which causes slight differences (which will need to be rebaselined)
BUG=skia:
Review URL: https://codereview.chromium.org/1045493002
I'd like to add a new API to SkStream for peeking - i.e. reading some
bytes without advancing the stream. This will be implemented for the
streams where it makes sense. I think the function should look
something like the following:
size_t peek(void* buffer, size_t bytesToRead) {
return this->onPeek(buffer, bytesToRead);
}
virtual size_t onPeek(void* buffer, size_t bytesToRead) {
return 0; // unimplemented base class.
}
In order to avoid confusion, I'd like to remove SkMemoryStream::peek(),
which is not currently used internally, by Chrome, or by Android as far
as I can tell. There is also another function does the same thing:
getPosition().
BUG=skia:3257
Review URL: https://codereview.chromium.org/1039373002
Replace the implicit curve intersection with a geometric curve intersection. The implicit intersection proved mathematically unstable and took a long time to zero in on an answer.
Use pointers instead of indices to refer to parts of curves. Indices required awkward renumbering.
Unify t and point values so that small intervals can be eliminated in one pass.
Break cubics up front to eliminate loops and cusps.
Make the Simplify and Op code more regular and eliminate arbitrary differences.
Add a builder that takes an array of paths and operators.
Delete unused code.
BUG=skia:3588
R=reed@google.com
Review URL: https://codereview.chromium.org/1037573004
Introduce a paint filter proxy base class as a SkDrawFilter replacement,
and convert SkDebugCanvas to use the new approach.
BUG=skia:3587
R=reed@google.com,mtklein@google.com,robertphillips@google.com,tomhudson@google.com
Review URL: https://codereview.chromium.org/1032173002
Add an interface for decoding scanlines, and implement that interface
in the PNG decoder.
Use a separate method to determine whether an image that used a type
with alpha was actually opaque.
SkScanlineDecoder.h:
New interface for decoding scanlines.
SkCodec.h:
Add getScanlineDecoder.
Add a virtual function (with non-virtual caller) for determining
whether the image truly had alpha. The client can call this to
determine if the image was actually opaque if it reported having alpha.
Remove code to sneakily change the passed in alpha type.
SkCodec_libpng.*:
Split up code onGetPixels into helper functions that can be shared with
the scanline decoder.
Implement scanline decoding.
Implement onReallyHasAlpha.
SkSwizzler.*:
Add a new SrcConfig as a default, which is invalid.
Add a function for setting fDstRow directly.
Assert fDstRow is not NULL.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1010903003
Subclasses of SkCanvas may need to override the behavior here - for
example, any proxy or deferred canvas may not know its own size and
need to delegate to another object.
We'll also work on reducing use of this function
(https://skbug.com/3569), but some of the current uses seem to be
semantically necessary.
R=reed@google.com
BUG=skia:3566
Review URL: https://codereview.chromium.org/1022423002
The implementation is nearly identical to Sk2f, with these changes:
- float32x2_t -> float64x2_t
- vfoo -> vfooq
- one extra Newton's method step in sqrt().
Also, generally fix NEON detection to be defined(SK_ARM_HAS_NEON).
SK_ARM_HAS_NEON is not being set on ARM64 bots right now (nor does the compiler
seem to set __ARM_NEON__), so this CL fixes everything up.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/e57b5cab261a243dcbefa74c91c896c28959bf09
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot,Build-Ubuntu-GCC-Arm64-Release-Android-Trybot
Review URL: https://codereview.chromium.org/1020963002
Adds an SSE2 version of the Color32A_D565 function, to replace
the existing SSE4 version. Also does some minor cleanup.
Performance improvement in the following Skia benchmarks.
Measured on Atom Silvermont:
Xfermode_SrcOver - x3
luma_colorfilter_large - x4.6
luma_colorfilter_small - x2
tablebench - ~15%
chart_bw - ~10%
Measured on Corei7 Haswell:
luma_colorfilter_large running SSE2 - x2
luma_colorfilter_large running SSE4 - x2.3
Also improves performance in WPS Office application and 2D subtest of 0xbenchmark on Android.
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
Review URL: https://codereview.chromium.org/923523002
The implementation is nearly identical to Sk2f, with these changes:
- float32x2_t -> float64x2_t
- vfoo -> vfooq
- one extra Newton's method step in sqrt().
Also, generally fix NEON detection to be defined(SK_ARM_HAS_NEON).
SK_ARM_HAS_NEON is not being set on ARM64 bots right now (nor does the compiler
seem to set __ARM_NEON__), so this CL fixes everything up.
BUG=skia:
Review URL: https://codereview.chromium.org/1020963002
(This is essentially a revert of https://codereview.chromium.org/503833002/.)
This was necessary back when SkPaint was flattened even for in-process use. Now that we only flatten SkPaint for cross-process use, there's no need to serialize UniqueIDs.
Note: SkDropShadowImageFilter is being constructed with a croprect and UniqueID (of 0) in Blink. I've made the uniqueID param default to 0 temporarily, until this rolls in and Blink can be changed. (Blink can't be changed first, since unlike the other filters, there's no constructor that takes a cropRect but not a uniqueID.)
BUG=skia:
Review URL: https://codereview.chromium.org/1019493002
Reason for revert:
arrrg. this is a staging nightmare. override required on the chrome side. must revert (again)
Original issue's description:
> Revert of Revert of Revert of Revert of Change device creation to see the (optional) layer-paint (patchset #1 id:1 of https://codereview.chromium.org/1001423002/)
>
> Reason for revert:
> chrome now has the new virtual, so trying again
>
> Original issue's description:
> > Revert of Revert of Revert of Change device creation to see the (optional) layer-paint (patchset #1 id:1 of https://codereview.chromium.org/1006923002/)
> >
> > Reason for revert:
> > platform_canvas tests failures
> >
> > skia_unittests (with patch) skia_unittests (with patch) PlatformCanvas.TranslateLayer failed 2
> > Flakiness dashboard
> >
> > failures:
> > PlatformCanvas.TranslateLayer
> > PlatformCanvas.FillLayer
> >
> > Original issue's description:
> > > Revert of Revert of Change device creation to see the (optional) layer-paint (patchset #1 id:1 of https://codereview.chromium.org/1008863002/)
> > >
> > > Reason for revert:
> > > guard in chrome has landed
> > >
> > > Original issue's description:
> > > > Revert of Change device creation to see the (optional) layer-paint (patchset #9 id:160001 of https://codereview.chromium.org/988413003/)
> > > >
> > > > Reason for revert:
> > > > need to have chrome opt-in for the older API before this can land (in chrome)
> > > >
> > > > Original issue's description:
> > > > > Change device creation to see the (optional) layer-paint
> > > > >
> > > > > Motivation:
> > > > >
> > > > > PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
> > > > >
> > > > > This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
> > > > >
> > > > > Committed: https://skia.googlesource.com/skia/+/1182d9a96b80bd12183ee7c81325a979a51ee0c0
> > > >
> > > > TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> > > > NOPRESUBMIT=true
> > > > NOTREECHECKS=true
> > > > NOTRY=true
> > > >
> > > > Committed: https://skia.googlesource.com/skia/+/0e040f7da2fdfeb49aa60d24117306e3b1e6ea90
> > >
> > > TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > >
> > > Committed: https://skia.googlesource.com/skia/+/f7076a13e2d4269903b34ef2780e1c84723e4477
> >
> > TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> >
> > Committed: https://skia.googlesource.com/skia/+/8e14d660b2a434bc708a70180c84210883611683
>
> TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com,reed@google.com
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/307d1ed129ff75eb64137dea75df858f9e250b69TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1005183003
Reason for revert:
chrome now has the new virtual, so trying again
Original issue's description:
> Revert of Revert of Revert of Change device creation to see the (optional) layer-paint (patchset #1 id:1 of https://codereview.chromium.org/1006923002/)
>
> Reason for revert:
> platform_canvas tests failures
>
> skia_unittests (with patch) skia_unittests (with patch) PlatformCanvas.TranslateLayer failed 2
> Flakiness dashboard
>
> failures:
> PlatformCanvas.TranslateLayer
> PlatformCanvas.FillLayer
>
> Original issue's description:
> > Revert of Revert of Change device creation to see the (optional) layer-paint (patchset #1 id:1 of https://codereview.chromium.org/1008863002/)
> >
> > Reason for revert:
> > guard in chrome has landed
> >
> > Original issue's description:
> > > Revert of Change device creation to see the (optional) layer-paint (patchset #9 id:160001 of https://codereview.chromium.org/988413003/)
> > >
> > > Reason for revert:
> > > need to have chrome opt-in for the older API before this can land (in chrome)
> > >
> > > Original issue's description:
> > > > Change device creation to see the (optional) layer-paint
> > > >
> > > > Motivation:
> > > >
> > > > PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
> > > >
> > > > This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
> > > >
> > > > Committed: https://skia.googlesource.com/skia/+/1182d9a96b80bd12183ee7c81325a979a51ee0c0
> > >
> > > TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > >
> > > Committed: https://skia.googlesource.com/skia/+/0e040f7da2fdfeb49aa60d24117306e3b1e6ea90
> >
> > TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> >
> > Committed: https://skia.googlesource.com/skia/+/f7076a13e2d4269903b34ef2780e1c84723e4477
>
> TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/8e14d660b2a434bc708a70180c84210883611683TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1005173004
Reason for revert:
platform_canvas tests failures
skia_unittests (with patch) skia_unittests (with patch) PlatformCanvas.TranslateLayer failed 2
Flakiness dashboard
failures:
PlatformCanvas.TranslateLayer
PlatformCanvas.FillLayer
Original issue's description:
> Revert of Revert of Change device creation to see the (optional) layer-paint (patchset #1 id:1 of https://codereview.chromium.org/1008863002/)
>
> Reason for revert:
> guard in chrome has landed
>
> Original issue's description:
> > Revert of Change device creation to see the (optional) layer-paint (patchset #9 id:160001 of https://codereview.chromium.org/988413003/)
> >
> > Reason for revert:
> > need to have chrome opt-in for the older API before this can land (in chrome)
> >
> > Original issue's description:
> > > Change device creation to see the (optional) layer-paint
> > >
> > > Motivation:
> > >
> > > PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
> > >
> > > This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
> > >
> > > Committed: https://skia.googlesource.com/skia/+/1182d9a96b80bd12183ee7c81325a979a51ee0c0
> >
> > TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> >
> > Committed: https://skia.googlesource.com/skia/+/0e040f7da2fdfeb49aa60d24117306e3b1e6ea90
>
> TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/f7076a13e2d4269903b34ef2780e1c84723e4477TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1001423002
Reason for revert:
guard in chrome has landed
Original issue's description:
> Revert of Change device creation to see the (optional) layer-paint (patchset #9 id:160001 of https://codereview.chromium.org/988413003/)
>
> Reason for revert:
> need to have chrome opt-in for the older API before this can land (in chrome)
>
> Original issue's description:
> > Change device creation to see the (optional) layer-paint
> >
> > Motivation:
> >
> > PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
> >
> > This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
> >
> > Committed: https://skia.googlesource.com/skia/+/1182d9a96b80bd12183ee7c81325a979a51ee0c0
>
> TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/0e040f7da2fdfeb49aa60d24117306e3b1e6ea90TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1006923002
Reason for revert:
need to have chrome opt-in for the older API before this can land (in chrome)
Original issue's description:
> Change device creation to see the (optional) layer-paint
>
> Motivation:
>
> PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
>
> This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
>
> Committed: https://skia.googlesource.com/skia/+/1182d9a96b80bd12183ee7c81325a979a51ee0c0TBR=halcanary@google.com,senorblanco@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1008863002
Motivation:
PDFDevice currently relies on 1) being told that the layer's paint has an imagefilter, and in the case, it creates a rasterdevice. It then relies on (2) canvas itself sniffing the layer's paint and offering to apply-the-imagefilter to call drawSprite instead of drawDevice.
This subtle interchange is fragile, and also does not support other unsupported PDF features like colorfilters. This CL is a step toward making this use-raster-instead-of-native approach to layers more completely in the subclass' hands.
Review URL: https://codereview.chromium.org/988413003
Unprotected reads -> relaxed reads.
Unprotected write -> relaxed write.
The only unprotected write we had was in SkTraceEvent, which it looks like we nabbed from Chrome at some point and changed only to silence TSAN. Chrome's version uses AtomicWord / NoBarrier_Load / NoBarrier_Store, which boils down to the same as here, intptr_t / relaxed load / relaxed store.
This leaves one place where we're lying a bit to TSAN, in include/core/SkLazyPtr.h where we're doing a data-dependent consume load. We're telling TSAN it's consume, but telling any other compiler to compile it as relaxed, given how they all upgrade consume to acquire. This eliminates a barrier for us on ARM. How do you guys deal with this? Just use a consume memory order, take the hit, and hope compilers get smarter one day?
BUG=chromium:465721
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/996763002
A glyph position when mapped from canvas space to device space may land
outside the bounds of the current 16 bit integer part of device space.
Device space is already limited to 32 bits for the integer part,
but for a short space in drawText and drawPosText it is currently
limited to 16 bits (SkFixed). Raise this limit by moving to 48.16.
This matches the current similar fix for measureText.
BUG=chromium:375322
Review URL: https://codereview.chromium.org/977623002
This changes SkScalarClampMax and SkScalarPin to use SkTMin and SkTMax.
This change allows compilers to more easily transform these operations
into fast max/min operarations as opposed to conditional branches.
Review URL: https://codereview.chromium.org/993593002
Clarify asColorFilter ...
1. Rename to isColorFilterNode for DAG reduction
2. Add asAColorFilter for removing the imagefilter entirely (future use-case)
Need layouttest rebaseline suppression before this can land in chrome...
https://codereview.chromium.org/984023004/
BUG=skia:
Review URL: https://codereview.chromium.org/982933002
Make a Via for DM which transforms a set of draws to be more like what
we'd see through the Android Framework's HWUI API. Only built inside
Android's framework because we depend on HWUI classes for half of
those transformations.
Tested with --config androidsdk-8888 and --config androidsdk-hwui.
R=djsollen@google.com,mtklein@google.com,reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/974913002
Reason for revert:
Fails on mac for some reason.
Also is a bit wrong, but this should not be reason for the failure..
Original issue's description:
> Add image as a draw type that can be filtered
>
> Add image as a draw type that can be filtered.
>
> This is needed when SkImage is added as an object to be drawn so that
> the draw is forwarded to SkBaseDevice. This would be used in making
> filters use SkImages.
>
> BUG=skia:3388
>
> Committed: https://skia.googlesource.com/skia/+/fa77eb1e51b9317ff993d1be504ada173b561e5fTBR=reed@google.com,bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3388
Review URL: https://codereview.chromium.org/980273002
Add image as a draw type that can be filtered.
This is needed when SkImage is added as an object to be drawn so that
the draw is forwarded to SkBaseDevice. This would be used in making
filters use SkImages.
BUG=skia:3388
Review URL: https://codereview.chromium.org/960783003
We're constructing blob run paints after the canvas draw filter has been
applied.
Instead, we need do defer text blob draw filters until we have access
to the full run paints.
BUG=skia:3494
R=reed@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/973973003
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
Review URL: https://codereview.chromium.org/963953002
DM:
Add a flag to use SkCodec instead of SkImageDecoder.
SkCodec:
Base class for codecs, allowing creation from an SkStream or an SkData.
An SkCodec, on creation, knows properties of the data like its width and height. Further calls can be used to generate the image.
TODO: Add scanline iterator
SkPngCodec:
New decoder for png. Wraps libpng. The code has been repurposed from SkImageDecoder_libpng.
TODO: Handle other destination colortypes
TODO: Substitute the transpose color
TODO: Allow silencing warnings
TODO: Use RGB instead of filler?
TODO: sRGB
SkSwizzler:
Simplified version of SkScaledSampler. Unlike the sampler, this object does no sampling.
TODO: Implement other swizzles.
Requires a gclient sync to pull down libpng.
BUG=skia:3257
Committed: https://skia.googlesource.com/skia/+/ca358852b4fed656d11107b2aaf28318a4518b49
(and then reverted)
Review URL: https://codereview.chromium.org/930283002
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/963953002
