Reason for revert:
Blink
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
>
> Committed: https://skia.googlesource.com/skia/+/0be685755f942baea26c66a87226b569fc17e960TBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1156583004
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4e
Review URL: https://codereview.chromium.org/1152553006
Reason for revert:
breaking tests
Original issue's description:
> Fix dst bound reported by SkTileImageFilter
>
> In the example from the bug we had the filter DAG:
>
> color filter (table)
> 0: xfermode filter (arith)
> 0: tile filter [0,80,34,114] -> [0,80,800,480]
> 0: color filter (table)
> 0: bitmap src 34x34 -> [0,80,34,114]
> 1: color filter (table)
> 0: picture filter [0, 80, 800, 480]
>
> computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
>
> This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
>
> BUG=493783
>
> Committed: https://skia.googlesource.com/skia/+/05be93bbdf09576f7903130e3b106b0a8c7c4b4eTBR=reed@google.com,senorblanco@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=493783
Review URL: https://codereview.chromium.org/1143083006
In the example from the bug we had the filter DAG:
color filter (table)
0: xfermode filter (arith)
0: tile filter [0,80,34,114] -> [0,80,800,480]
0: color filter (table)
0: bitmap src 34x34 -> [0,80,34,114]
1: color filter (table)
0: picture filter [0, 80, 800, 480]
computeFastBounds was coming out of the DAG with a bound of [0,80,34,114] which didn't represent the pixels that would be drawn.
This CL updates SkTileImageFilter to correctly set the bound for the pixels it will hit.
BUG=493783
Review URL: https://codereview.chromium.org/1152553006
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
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
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
(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
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
This makes SkComposeImageFilter::computeFastBounds compose its
filters' bounds (rather than falling back to
SkImageFilter::computeFastBounds, which takes the union of the bounds).
This also makes SkComposeImageFilter::onFilterImage correctly handle
an offset produced when applying the inner filter; such offsets were
previously ignored.
BUG=chromium:453924
Review URL: https://codereview.chromium.org/908273002
This adds sk_memory_barrier(), implemented using sk_atomic_fetch_add() on an uninitialized variable. If that becomes a problem we can drop this to the porting layer, using std::atomic_thread_fence() / __atomic_thread_fence() / __sync_synchronize().
The big win is that ref() doesn't generate a memory barrier any more on ARM.
This is an instance of SkSafeRef() in SkPaint(const SkPaint&) after this CL:
4d0: 684a ldr r2, [r1, #4]
4d2: 6018 str r0, [r3, #0]
4d4: b13a cbz r2, 4e6 <_ZN7SkPaintC1ERKS_+0x2e>
4d6: 1d10 adds r0, r2, #4
4d8: e850 4f00 ldrex r4, [r0]
4dc: 3401 adds r4, #1
4de: e840 4500 strex r5, r4, [r0]
4e2: 2d00 cmp r5, #0
4e4: d1f8 bne.n 4d8 <_ZN7SkPaintC1ERKS_+0x20>
Here's the before, pretty much the same with two memory barriers surrounding the ref():
4d8: 684a ldr r2, [r1, #4]
4da: 6018 str r0, [r3, #0]
4dc: b15a cbz r2, 4f6 <_ZN7SkPaintC1ERKS_+0x3e>
4de: 1d10 adds r0, r2, #4
4e0: f3bf 8f5f dmb sy
4e4: e850 4f00 ldrex r4, [r0]
4e8: 3401 adds r4, #1
4ea: e840 4500 strex r5, r4, [r0]
4ee: 2d00 cmp r5, #0
4f0: d1f8 bne.n 4e4 <_ZN7SkPaintC1ERKS_+0x2c>
4f2: f3bf 8f5f dmb sy
The miscellaneous files in here are just fixups to explicitly include SkMutex.h,
instead of leeching it off SkRefCnt.h.
No public API changes.
TBR=reed@google.com
Build trybots seem hosed.
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/896803002
This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.
for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end
BUG=skia:
Review URL: https://codereview.chromium.org/806653007
There are only a handful of SkFlattenables that are not flattenable. That
there are any seems highly illogical. To make this look less like a normal
thing, this removes both macros that marked SkFlattenables as non-flattenable
(in slightly different ways).
The handful of SkFlattenables in our codebase that can't be flattened now
assert violently that they can't be flattened. They're internal or
part of animator... places where we'll never actually flatten them.
TestLooper and DummyRasterizer were so trivial that I just made them flattenable.
BUG=skia:
Review URL: https://codereview.chromium.org/841753002
This fixes errors like this:
../../include/gpu/effects/GrPorterDuffXferProcessor.h:27:25: error:
'name' overrides a member function but is not marked 'override'
[-Werror,-Winconsistent-missing-override]
BUG=skia:3075
TEST=ninja -C out/Debug skia_lib
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/804813002
This was needed for pictures before v33, and we're now requiring v35+.
Will follow up with the same for skia/ext/pixel_ref_utils_unittest.cc
BUG=skia:
Review URL: https://codereview.chromium.org/769953002
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
The SkRectShaderImageFilter had the same bug as previously fixed for
SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste
the implementation, this change makes all filters with 0 inputs return
their source bounds, instead of returning false.
BUG=427251
Review URL: https://codereview.chromium.org/681643003
Reason for revert:
try again
Original issue's description:
> Fix bounds computation of all 0-input filters.
>
> The SkRectShaderImageFilter had the same bug as previously fixed for
> SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste
> the implementation, this change makes all filters with 0 inputs return
> their source bounds, instead of returning false.
>
> BUG=427251
>
> Committed: https://skia.googlesource.com/skia/+/ba036cc82b5a543a13cafd11a19ba0e3087fca38TBR=bsalomon@google.com,senorblanco@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=427251
Review URL: https://codereview.chromium.org/678273002
The SkRectShaderImageFilter had the same bug as previously fixed for
SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste
the implementation, this change makes all filters with 0 inputs return
their source bounds, instead of returning false.
BUG=427251
Review URL: https://codereview.chromium.org/681643003
This is basically how blink uses the filter. Currently, I can't use it for "ShadowOnly" mode with the filter at all, but instead of copying the code and risking to have the codepaths diverge, I'm simply going to add the option here.
BUG=skia:
Review URL: https://codereview.chromium.org/646213004
9fa60d ("Simplify flattening to just write enough ... ") simplified just
a tad too much. In particular, it disabled deserialization of
SkImageFilter's uniqueID, which in turn caused the failure of
SkImageFilter's cache, which caused a large regression in Chrome's SVG
filter performance.
The medium-term fix is to switch to the new SkRecordDraw SkPicture
backend, which will make the unique IDs unnecessary.
This change is an "in case of emergecy" CL, in the event that there are
problems switching on the new backend in Chrome. For that reason, it's
minimalist: only the filters used by Chrome are modified, and whitespace
changes are kept to a minimum. In this way, it should be easy to revert
once the new backend goes in.
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/503833002
Now that all creation of SkImageFilters goes through
factory Create() methods, there's no real reason for the
convenience constructors. Some SkImageFilter subclasses
which actually have zero DAG-able inputs were passing NULL
to the superclass constructor. This actually means 1 input,
with a NULL value, not zero inputs. This becomes more
relevant for the upcoming cache infrastructure, where this
indicates that the filter will use its src input, where in
fact some of these filters do not (they are image generators
only).
Limiting SkImageFilter to a single constructor resolves this
ambiguity.
Along the way, I removed all of the default parameters to
the constructors, since the Create methods always call them
with the full argument list.
BUG=skia:
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/376953003
When drawing perlin noise, generate noise at the resolution determined
by CTM, not by the resolution at construction time. This required moving
the generation of PaintingData to getContext() and asNewEffect() for the
raster and GPU paths, respectively.
It also required adjusting the matrices used during rendering
to be translate-only.
R=sugoi@chromium.org, bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/358903002
From inside GrContext, we have a need to create an SkPath an original path and
some dashing info. We do not have access to the original path effect so we need
a way to make the FilterPath function accessible outside of the effect. So I moved
the core filterPath code (and all need helper functions) out of SkDashPathEffect
and created a SkDashPath in utils to store these helper functions.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/576dcdc793a762ec63fbecdbfd5768066b548fe5
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/314623004
The new signature is:
bool asNewEffect(GrContext* context, const SkPaint& paint, GrColor* grColor, GrEffectRef** grEffect, const SkMatrix* localMatrixOrNull) const;
It will fix the hack for skcolorshader by modifying the GrColor parameter in SkGr::SkPaint2GrPaintShader.
BUG=skia:2646
R=jvanverth@google.com, bsalomon@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/318923005
From inside GrContext, we have a need to create an SkPath an original path and
some dashing info. We do not have access to the original path effect so we need
a way to make the FilterPath function accessible outside of the effect. So I moved
the core filterPath code (and all need helper functions) out of SkDashPathEffect
and created a SkDashPath in utils to store these helper functions.
BUG=skia:
R=bsalomon@google.com, reed@google.com, rmistry@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/314623004
In SkLayerRasterizer::snapshotRasterizer() and ::detachRasterizer(),
if no layers have been added, do not attempt to create an
SkLayerRasterizer. Instead, return NULL.
This fixes an error when running tests on Android.
Update dox to state that NULL may be returned.
Add tests.
R=reed@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/313653006
Add a new GM that exercises tiled drawing all pixel-moving filters
(and some non-pixel-moving ones) and compares it against non-tiled
drawing of the same filters. Fixing this test revealed that tile and
matrix convolution filters had no onFilterBounds() traversals
(test-driven development FTW). Tile requires (conservatively) the
bounds to include the whole source rect, since it may end up in the
result. Matrix convolution requires the bounds to be offset by the
kernel size and target.
R=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/258243005
git-svn-id: http://skia.googlecode.com/svn/trunk@14432 2bbb7eff-a529-9590-31e7-b0007b416f81
