Before this change, GrStencilAndCoverTextContext would send 6-float
affine transforms to drawPaths for every glyph. This updates it to
concat the text scale onto the context matrix, and then only send
2-float translates (or 1-float x-translates when possible).
Also adds a glyph_pos_align test to gm that exercises the newly added
codepaths, and starts ignoring a few gm tests with benign pixel diffs
until we can rebaseline.
BUG=skia:
R=bsalomon@google.com, kkinnunen@nvidia.com, jvanverth@google.com, bungeman@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/406523003
Each patch defines a method genMesh that produces the geometry to draw. To do this they receive a SkPatchMesh object which they need to initialize in order to set up how the data is going to be formatted. Later they call function like setColor or pointAt to set the values at a specific index, the SkMeshPatch object handles the indices based on the format and makes it transparent to the client.
Added a slide to sample app to show how to set up this classes and how they interact.
BUG=skia:
R=jvanverth@google.com, egdaniel@google.com, bsalomon@google.com
Author: dandov@google.com
Review URL: https://codereview.chromium.org/405163003
This is a first piece of the GPU YUV decoder, which is the actual effect that performs the conversion. For now, it simply applies the conversion matrix, since it is all I need. I may add modes if different matrices need to be applied or if I add color profile support here.
I'll try to keep these cls short and easy to review, but there should be a few of them coming once this one is in.
BUG=skia:
R=senorblanco@chromium.org, senorblanco@google.com, reed@google.com, bsalomon@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/378503006
Reason for revert:
Rebaseline CL is ready to be submitted
Original issue's description:
> Revert of Fix SkPaint::measureText for stroked hairline text (https://codereview.chromium.org/335603003/)
>
> Reason for revert:
> Caused many shadertext GM failures
>
> Original issue's description:
> > Fix SkPaint::measureText for stroked hairline text
> >
> > SkPaint::measureText and text drawing used different criteria for
> > determining whether text should be drawn as paths or not.
> >
> > Adds tests glyph_pos_(h/n)_(s/f/b) to test the text rendering and the glyph
> > positioning in the rendering. Mainly added in order to define what is the
> > expected text rendering when hairline stroke is used with various transform
> > options.
> >
> > The testcase also tries to note or highlight the fact that SkPaint::measureText
> > is not expected to produce intuitively matching results when compared to a
> > rendering, if the rendering is done so that the device ends up having a device
> > transform.
> >
> > This fixes the glyph_pos_h_s (hairline, stroked) test-case.
> >
> > Ignore shadertext2_pdf-poppler.png gm on
> > Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug temporarily, as that fails.
> >
> > Committed: https://skia.googlesource.com/skia/+/196af738027c5e18c3eb792dbcaf90ef27821793
>
> TBR=jvanverth@google.com,reed@google.com,kkinnunen@nvidia.com
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/abc9bb55ddfeb4b1a7acc335a34841fddcd22d27R=jvanverth@google.com, reed@google.com, kkinnunen@nvidia.comTBR=jvanverth@google.com, kkinnunen@nvidia.com, reed@google.com
NOTREECHECKS=true
NOTRY=true
Author: rmistry@google.com
Review URL: https://codereview.chromium.org/349153005
Reason for revert:
Caused many shadertext GM failures
Original issue's description:
> Fix SkPaint::measureText for stroked hairline text
>
> SkPaint::measureText and text drawing used different criteria for
> determining whether text should be drawn as paths or not.
>
> Adds tests glyph_pos_(h/n)_(s/f/b) to test the text rendering and the glyph
> positioning in the rendering. Mainly added in order to define what is the
> expected text rendering when hairline stroke is used with various transform
> options.
>
> The testcase also tries to note or highlight the fact that SkPaint::measureText
> is not expected to produce intuitively matching results when compared to a
> rendering, if the rendering is done so that the device ends up having a device
> transform.
>
> This fixes the glyph_pos_h_s (hairline, stroked) test-case.
>
> Ignore shadertext2_pdf-poppler.png gm on
> Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug temporarily, as that fails.
>
> Committed: https://skia.googlesource.com/skia/+/196af738027c5e18c3eb792dbcaf90ef27821793R=jvanverth@google.com, reed@google.com, kkinnunen@nvidia.comTBR=jvanverth@google.com, kkinnunen@nvidia.com, reed@google.com
NOTREECHECKS=true
NOTRY=true
Author: rmistry@google.com
Review URL: https://codereview.chromium.org/354433002
SkPaint::measureText and text drawing used different criteria for
determining whether text should be drawn as paths or not.
Adds tests glyph_pos_(h/n)_(s/f/b) to test the text rendering and the glyph
positioning in the rendering. Mainly added in order to define what is the
expected text rendering when hairline stroke is used with various transform
options.
The testcase also tries to note or highlight the fact that SkPaint::measureText
is not expected to produce intuitively matching results when compared to a
rendering, if the rendering is done so that the device ends up having a device
transform.
This fixes the glyph_pos_h_s (hairline, stroked) test-case.
Ignore shadertext2_pdf-poppler.png gm on
Test-Ubuntu13.10-ShuttleA-NoGPU-x86_64-Debug temporarily, as that fails.
R=jvanverth@google.com, reed@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/335603003
This will be used in Blink to accommodate matrices that contain
rotation or shearing. This is a generalization of SkResizeImageFilter,
so I've replaced all uses of SkResizeImageFilter in Skia. (It might be
easier to review by diffing it with SkResizeImageFilter, too.)
R=reed@google.com
Review URL: https://codereview.chromium.org/211103006
git-svn-id: http://skia.googlecode.com/svn/trunk@13941 2bbb7eff-a529-9590-31e7-b0007b416f81
Fix GPU displacement with expanding crop rects, and re-enable the
imagefilterscropexpand GM. There were two bugs: the result texture was
being created at input color bitmap size, not the cropped bounds size,
and the matrix in GrContext was not being set to identity before draw.
R=junov@chromium.org
Review URL: https://codereview.chromium.org/195973007
git-svn-id: http://skia.googlecode.com/svn/trunk@13844 2bbb7eff-a529-9590-31e7-b0007b416f81
NOTE: this patch set is based on https://codereview.chromium.org/189913021/,
and needs that patch to land first.
Until now, crop rects in Skia have only been able to reduce
the size of the destination bounds, but not expand them.
SVG semantics require the latter as well. The heart of
the change is in applyCropRect(), which now assigns each
edge, instead of doing an intersection with the crop rect.
In order to support this (and still work well with tiled
drawing) we need to clip the resulting crop rect to the
clipping region of the filters. This uses the Context struct
previously landed from https://codereview.chromium.org/189913021/.
Many of the pixel loops are not yet ready to handle a
destination rect larger than the source rect. So we provide
a convenience version of applyCropRect() which creates an
offscreen and pads it out with transparent black. Once the
pixel loops and shaders have been fixed to support larger
destination bounds, they should be switched back to the
non-drawing version of applyCropRect().
BUG=skia:
R=bsalomon@google.com, reed@google.com
Committed: https://code.google.com/p/skia/source/detail?r=13805
Review URL: https://codereview.chromium.org/198003008
git-svn-id: http://skia.googlecode.com/svn/trunk@13809 2bbb7eff-a529-9590-31e7-b0007b416f81
NOTE: this patch set is based on https://codereview.chromium.org/189913021/,
and needs that patch to land first.
Until now, crop rects in Skia have only been able to reduce
the size of the destination bounds, but not expand them.
SVG semantics require the latter as well. The heart of
the change is in applyCropRect(), which now assigns each
edge, instead of doing an intersection with the crop rect.
In order to support this (and still work well with tiled
drawing) we need to clip the resulting crop rect to the
clipping region of the filters. This uses the Context struct
previously landed from https://codereview.chromium.org/189913021/.
Many of the pixel loops are not yet ready to handle a
destination rect larger than the source rect. So we provide
a convenience version of applyCropRect() which creates an
offscreen and pads it out with transparent black. Once the
pixel loops and shaders have been fixed to support larger
destination bounds, they should be switched back to the
non-drawing version of applyCropRect().
BUG=skia:
R=bsalomon@google.com, reed@google.com
Review URL: https://codereview.chromium.org/198003008
git-svn-id: http://skia.googlecode.com/svn/trunk@13805 2bbb7eff-a529-9590-31e7-b0007b416f81
This change makes kSkipTiled_Flag also skip --tileGrid and --rtree.
All GMs which were passing kSkipTiled_Flag before were also passing
kSkipPicture_Flag, which also skips tilegrid and rtree, so this should
have no effect on them, but provides a smaller hammer for GMs which
still want to test picture playback, but not tiling.
The exception is magnifier, which was passing only kSkipTiled_Flag,
but magnifier is an odd beast and not web-exposed, so I'm not worried
about reducing its coverage slightly.
R=scroggo@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/165723009
git-svn-id: http://skia.googlecode.com/svn/trunk@13514 2bbb7eff-a529-9590-31e7-b0007b416f81
SkResizeImageFilter resizes all the pixels from its input (subject to
the input's crop rect), but the offset to be applied was incorrect.
It should take the CTM into account, so that the origin of the resize is
the world space origin, unaffected by whatever clipping is applied.
New GM imageresizetiled exercises the behaviour under
impl-side-painting-like conditions, and existing GMs now have resize
cases added.
R=reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/168283006
git-svn-id: http://skia.googlecode.com/svn/trunk@13506 2bbb7eff-a529-9590-31e7-b0007b416f81
Image filters in Skia currently clip the size of the the offscreen
bitmap used for filtering to the device clip bounds. This means that
any pixel-moving filter (e.g., blur) has edge artifacts at the clip
boundaries. This is problematic for tiling, where a single SkPicture
is played back with a clip set to the tile boundaries.
By implementing the onFilterBounds() traversal, and using it in
saveLayer() when a filter is present, we can clip the layer to the
expanded clip rect. Note that this requires that the traversal be
performed in reverse as compared to computeFastBounds(). (It's also
done in device space, unlike computeFastBounds()).
New test imagefiltersclipped tests pixel-moving filters when clipped
by various clip rects.
New test imageblurtiled tests tiled (compositor-style) rendering of
blurred text. There should be no artifacts at the tile boundaries.
BUG=337831
R=reed@google.com
Review URL: https://codereview.chromium.org/23011012
git-svn-id: http://skia.googlecode.com/svn/trunk@13323 2bbb7eff-a529-9590-31e7-b0007b416f81
This revealed that the displacement map was not handling clipping or upstream cropping at all well (the color would "swim" through the displacement at the edge of the clip rect). Fixed by passing through the correct offsets to the bitmap accesses in both raster and GPU paths. Same for morphology.
R=sugoi@google.com
Review URL: https://codereview.chromium.org/137053003
git-svn-id: http://skia.googlecode.com/svn/trunk@13127 2bbb7eff-a529-9590-31e7-b0007b416f81
This also includes some changes to the xfermodeimagefilter and tileimagefilter GMs to properly handle the CTM. This worked before only because SkBitmapSource was ignoring the CTM. Now that it respects it, we need to give the correct transform. This also means the GMs now work while zoomed. It also implements CTM support for SkTileImageFilter.
NOTE: this will require rebaselining a number of imagefilter GMs on Nexus4, since they render in perspective (using the CTM). The changes to the results should all be improvements.
R=reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/106933002
git-svn-id: http://skia.googlecode.com/svn/trunk@12571 2bbb7eff-a529-9590-31e7-b0007b416f81
Note: I initially implemented this as a fully-generic SkResizeImageFilter, but then I realized that the dstRect should always be transformed by the filter matrix, but that the srcRect should not (since it's specified relative to the dimensions of the original bitmap). Since this would be confusing for someone attempting to use this as a generic resizing filter, I decided to build the functionality into SkBitmapSource instead.
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/106933002
git-svn-id: http://skia.googlecode.com/svn/trunk@12522 2bbb7eff-a529-9590-31e7-b0007b416f81
There were 4 classes in blink that derived from SkImageFilter :
- TileImageFilter -> SkTileImageFilter
- OffsetImageFilter -> SkOffsetImageFilter (already existed)
- FloodImageFilter -> SkFloodImageFilter
- CompositeImageFilter -> SkCompositeImageFilter
All functions were copied as is, without modification (except for warnings fixes), except for the offset filter, which was merged into the existing SkOffsetImageFilter class, as a special case when a crop rect is provided. Since the names won't clash with the names in blink, it should be easy to integrate them in blink later and fix issues, if needed.
BUG=
R=senorblanco@google.com, senorblanco@chromium.org, bsalomon@google.com, reed@google.com, mtklein@google.com
Author: sugoi@chromium.org
Review URL: https://chromiumcodereview.appspot.com/24157005
git-svn-id: http://skia.googlecode.com/svn/trunk@11475 2bbb7eff-a529-9590-31e7-b0007b416f81
This reverts commit 16a6c9d28c8ef6f827d50ef258005fa5ec971bd9.
Seems to be breaking all of the windows debug bots in GM.
git-svn-id: http://skia.googlecode.com/svn/trunk@10737 2bbb7eff-a529-9590-31e7-b0007b416f81
In order to preserve the immutability of SkImageFilters, the crop rect is passed as a constructor parameter. If NULL (the default), the bounds of the input image are used, as before.
This also tightens up the boundary handling for SkImageBlurFilter on the GPU backend. Where we were previously using clamping semantics, we now respect decal semantics (so we don't oversaturate the edges). This brings the GPU and raster backends into closer alignment, but will require some new baselines for the GPU tests.
At a minimum, the following tests will need new baselines: imageblur, imagefiltersbase, imagefilterscropped, spritebitmap.
R=reed@google.com
Committed: https://code.google.com/p/skia/source/detail?r=10251
Review URL: https://codereview.chromium.org/19775006
git-svn-id: http://skia.googlecode.com/svn/trunk@10338 2bbb7eff-a529-9590-31e7-b0007b416f81
In order to preserve the immutability of SkImageFilters, the crop rect is passed as a constructor parameter. If NULL (the default), the bounds of the input image are used, as before.
This also tightens up the boundary handling for SkImageBlurFilter on the GPU backend. Where we were previously using clamping semantics, we now respect decal semantics (so we don't oversaturate the edges). This brings the GPU and raster backends into closer alignment, but will require some new baselines for the GPU tests.
At a minimum, the following tests will need new baselines: imageblur, imagefiltersbase, imagefilterscropped, spritebitmap.
R=reed@google.com
Review URL: https://codereview.chromium.org/19775006
git-svn-id: http://skia.googlecode.com/svn/trunk@10251 2bbb7eff-a529-9590-31e7-b0007b416f81
For the raster path, we do a straightforward 2-pass method: draw background, then composite the foreground over it.
For the GPU path, if the xfermode can be expressed as an effect, we build an effect with the background texture incorporated, then do a single-pass draw fetching both foreground and background textures, and compositing to the result. If the xfermode is expressed as src/dst coefficients, we do a 2-pass draw as in the raster path and use fixed-function blending.
R=bsalomon@google.com, reed@google.com
Review URL: https://codereview.chromium.org/16125008
git-svn-id: http://skia.googlecode.com/svn/trunk@9373 2bbb7eff-a529-9590-31e7-b0007b416f81
SkImage calls functions on SkImageDecoder and SkImageEncoder. This
is desired behavior, and it is also desired to include SkImage as
a part of core. In order to keep core from depending on images,
update SkImageDecoder_empty.cpp to implement all of SkImageDecoder
and SkImageEncoder. This file will be built by chrome (in
https://codereview.chromium.org/15960015).
Move force_linking from SkImageDecoder.cpp to its own file. It must
be called to force linking with the image decoders if desired. Call
the function in tools that need it:
sk_image
render_pictures
render_pdfs
sk_hello
filter
bench_pictures
debugger
SkImageDecoder:
Derive from SkNoncopyable, instead of duplicating its
hiding of constructors.
skhello:
Return rather than trying to write a null SkData to the stream.
Revert "Hamfistedly removed core dependence on images"
(commit 0f05f682a90bc125323677abf3476e1027d174f5) and
"Move SkImage::encode to SkImage_Codec.cpp."
(commit 83e47a954d0bf65439f3d9c0c93213063dd70da3.)
These two commits were temporary fixes that this change
cleans up.
SkSnapshot.cpp:
Check for a NULL encoder returned by SkImageEncoder::Create.
BUG=https://code.google.com/p/skia/issues/detail?id=1275R=djsollen@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/15806010
git-svn-id: http://skia.googlecode.com/svn/trunk@9364 2bbb7eff-a529-9590-31e7-b0007b416f81
Add an option to SkCanvas to turn on path
ops when combining clips.
Allow Op() to use one of the input paths
as an output path.
Fix a bug in Op() when the minuend is empty
and the subtrahend is not (for difference).
Change the build to allow core to depend on pathops.
Review URL: https://codereview.chromium.org/14474002
git-svn-id: http://skia.googlecode.com/svn/trunk@8855 2bbb7eff-a529-9590-31e7-b0007b416f81
