Add a test that we get the same color back after calling SkBitmap::eraseColor, modulo rounding.
Also update some incorrect docs.
BUG=skia:4297
Review URL: https://codereview.chromium.org/1521673002
visual bench run on Mac Pro
curr/maxrss loops min median mean max stddev samples config bench
100/100 MB 16 412µs 413µs 413µs 414µs 0% ▄▁▇▄▄▄▄█▄▃▅ gpu warmupbench
101/102 MB 32 547µs 548µs 611µs 1.24ms 34% █▁▁▁▁▁▁▁▁▁▁ gpu image-filter-sprite-draw-image
102/103 MB 32 547µs 548µs 721µs 1.23ms 41% █▁▇▁▁█▁▁▁▁▁ gpu image-filter-sprite-draw-bitmap
103/103 MB 64 546µs 546µs 546µs 547µs 0% ▆▄▂▁▇█▅▇▅▇▃ gpu image-filter-sprite-draw-sprite
Should have no effect on Chrome while SK_SUPPORT_LEGACY_LAYER_BITMAP_IMAGEFILTERS is defined (which it is in chrome)
BUG=skia:1073
Review URL: https://codereview.chromium.org/1491293002
There may be other (better?) ways to enable this. For example, if we queried the device *before* we init our root DeviceCM, we wouldn't need this flag in InitFlags, since the device already has a virtual to opt-in ...
BUG=skia:
Review URL: https://codereview.chromium.org/1458153003
Motivation:
- perf win for clients that overwrite the surface after a snapshot.
- may allow us to eliminate SkDeferredCanvas, as this was its primary advantage.
BUG=skia:
Review URL: https://codereview.chromium.org/1236023004
this also exposes nine-patch drawing directly to devices, and creates a shared iterator for unrolling a nine-patch into single rect->rect draws.
BUG=skia:
Review URL: https://codereview.chromium.org/1211583003
This CL continues cleaning up Skia's usage of SkSurfaceProps. It:
Removes the duplicate SkSurfaceProps object from SkImageFilter::Proxy.
Removes a dispreferred ctor from SkCanvas
Removes the initForRootLayer entry point from SkDevice (since the root device and the canvas should always have the same pixel geometry now).
Review URL: https://codereview.chromium.org/1201983006
Implemented by extracting out the non-scale/translate components
and applying that post-filter as an SkMatrixImageFilter.
BUG=skia:
Review URL: https://codereview.chromium.org/1120043002
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
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
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
Swap render target of the gpu device instead of creating a new gpu
device when making a copy-on-write upon surface modification.
This removes the SkCanvas::setRootDevice which contains problematic code
when trying to increase the use of SkImages internally in Skia.
BUG=skia:3388
Review URL: https://codereview.chromium.org/925343002
This CL cleans up the existing violations and enables the
build time check to ensure that we don't regress.
The motiviation behind this change is to allow clients who include
our headers to be able to build with this warning enabled.
Review URL: https://codereview.chromium.org/726923002
Under the hood, add SkPixelGeometry to the CreateInfo for new devices, allowing them to see their geometry (SkDeviceProperties) up front, rather than having it changed later.
The only exception is for devices that are used on the root-layer, where we don't see the device until after the fact (at least as long as we allow clients to attach a device to a canvas externally).
We also filter the geometry when we're creating a layer, so we can disable LCD text automatically if the layer is not marked as opaque.
NOTRY=True
-- gammatext flake?
Review URL: https://codereview.chromium.org/719253002
This CL:
1) removes the EXPERIMENTAL_optimize on SkCanvas & SkDevice
2) moves the saveLayer gathering step to endRecording
3) Replaces GPUOptimize with SkRecordComputeLayers
4) Update bench_pictures & render_pictures to provide the new flag
#2 also necessitated moving the BBH computation (and record optimization) out of SkPicture's ctor (and into endRecording)
Review URL: https://codereview.chromium.org/718443002
drawPatch now receives as parameter const SkPoint cubics[12]
Adjusted derived classes and serialization.
Ajusted GM's and benches that take into account combinations of optional
parameters, the scale of the patch and 4 different types of patches.
Planning on adding the extra functionality of SkPatch in another CL.
BUG=skia:
R=egdaniel@google.com, reed@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/463493002
Added function SkCanvas::drawPatch to the API. This function
receives the patch to draw and the paint.
Added function SkBaseDevice::drawPatch to the API. This function also receives the patch to draw and the paint.
Currently SkGpuDevice and SkBitmapDevice generate the mesh taking into
account the scale factor and call the corresponding device's drawVertices.
BUG=skia:
R=jvanverth@google.com, egdaniel@google.com, bsalomon@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/424663006
This is a follow up to https://codereview.chromium.org/338913002/. More
tweaks to allow migrating clients to the new API.
1) switch the shim call direction willSave(SaveFlags) -> willSave()
(internal users are still using the former, so external overriders of
the latter will not be notified otherwise - doh)
2) ensure willSave() stays visible in SkProxyCanvas (Chromium's
TimingCanvas attempts to call it explicitly).
BUG=skia:2297
R=reed@google.com
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/334393008
(
This is intended to facilitate efficient kMatrix_SaveFlags emulation
on restore():
* collect all clip stack elements for the current save count into a
side clip stack
* canvas.restore(everything)
* replay the collected clip ops to restore the initial clip state
=> we restored the matrix but the clip state is unchanged
)
Two main changes:
* expose the save count for SkClipStack::Element
* expose a replay method for the same (logic relocated from
SkCanvas::replayClips)
The SkCanvas::ClipVisitor shuffling is to enable forward decl
in SkClipStack.h (cannot fwdecl a nested class).
R=reed@google.com, robertphillips@google.comTBR=reed@google.com
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/269693003
