Sometimes, when ScriptShape is presented with a surrogate pair which does
not map to a glyph, it returns two space glyphs instead of .notdef (0).
Detect this class of issues and handle appropriately.
git-svn-id: http://skia.googlecode.com/svn/trunk@11660 2bbb7eff-a529-9590-31e7-b0007b416f81
I noticed SkMatrix <-> SkMatrix44 conversions were dropping the
perspective values on the floor. As we use SkMatrix44 heavily in
Chromium, I'm concerned this missing code will cause a bug eventually.
It should be correct to simply use the bottom row of the 4x4 matrix
excluding the third column.
Previously committed and reverted, second attempt with fix for
incorrect use of SkMScalar/SkScalar.
BUG=
R=reed@google.com, caryclark@google.com
Author: aelias@chromium.org
Review URL: https://codereview.chromium.org/25484006
git-svn-id: http://skia.googlecode.com/svn/trunk@11624 2bbb7eff-a529-9590-31e7-b0007b416f81
I noticed SkMatrix <-> SkMatrix44 conversions were dropping the
perspective values on the floor. As we use SkMatrix44 heavily in
Chromium, I'm concerned this missing code will cause a bug eventually.
It should be correct to simply use the bottom row of the 4x4 matrix
excluding the third column.
BUG=
R=reed@google.com
Author: aelias@chromium.org
Review URL: https://codereview.chromium.org/25484006
git-svn-id: http://skia.googlecode.com/svn/trunk@11622 2bbb7eff-a529-9590-31e7-b0007b416f81
Before, gradients would only interpolate the linear portion of the
quadratic equation if there was no perspective. This updates them to
do so even in the case that there is perspective. The rearrangement
of math causes noise differences in the following gm tests:
gradients_no_texture_gpu
gradients_view_perspective_gpu
gradients_local_perspective_gpu
gradients_gpu
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/25645006
git-svn-id: http://skia.googlecode.com/svn/trunk@11595 2bbb7eff-a529-9590-31e7-b0007b416f81
To dodge the problem, call computeBounds when creating the global empty path
ref.
There's still another race here, which is that we can race to create the empty
path ref in the first place. As written we can conceivably allocate an
arbitrary number of empty path refs, one of which ends up pointed to by the
global variable at the end.
I've punted on fixing this for now because 1) tsan has not complained yet; 2) I
think it can be fixed by the same approach as we can fix the memsets in
25415003, so I want to wait to see how that review goes
first.
BUG=
R=reed@google.com, robertphillips@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/25745003
git-svn-id: http://skia.googlecode.com/svn/trunk@11576 2bbb7eff-a529-9590-31e7-b0007b416f81
Only implemented for PNG.
Add a getter and setter, and sets the default to false in the
constructor. Also copies the setting in copyFieldsToOther.
Fix an indpendent bug where fDitherImage was not being copied in
copyFieldsToOther.
In SkScaledBitmapSampler::begin, consolidate the settings passed in
by passing a const reference to the decoder. The decoder can be
referenced for its settings of dither, unpremultiplied, and now
skipping writing zeroes. Update callers to use the new API. In png
decoder, rather than passing around a pointer to an initial
read of getDitherImage, and potentially changing it, look at the
field on the decoder itself, and modify it directly. This is a
change in behavior - now if that same decoder is used to decode
a different image, the dither setting has changed. I think this is
okay because A) the typical use case is to use a new decoder for
each decode, B) we do not make any promises that a decode does not
change the decoder and C) it makes the code in SkScaledBitmapSampler
much cleaner.
In SkScaledBitmapScampler, add new row procs for skipping zeroes. Now
that choosing the row proc has five dimensions (src config, dst config,
dither, skip writing zeroes, unpremultiplied), use a new method: each
src/dst combination has a function for choosing the right proc depending
on the decoder.
SkScaledBitmapScampler::RowProc is now public for convenience.
Remove Sample_Gray_D8888_Unpremul, which is effectively no different
from Sample_Gray_D8888.
In cases where unpremultiplied was trivial, such as 565 and when
sampling from gray, decoding may now succeed.
Add a benchmark (currently disabled) for comparing the speed of skipping
writing zeroes versus not skipping. For this particular image, which is
mostly transparent pixels, normal decoding took about 3.6 milliseconds,
while skipping zeroes in the decode took only about 2.5 milliseconds
(this is on a Nexus 4). Presumably it would be slower on an image
with a small amount of transparency, but there will be no slowdown
for an image which reports that it has no transparency.
In SkImageRef_ashmem, always skip writing zeroes, since ashmem
memory is guaranteed to be initialized to 0.
Add a flag to skip writing zeroes in skimage.
Add a regression test for choosing the rowproc to ensure I did not
change any behavior accidentally.
BUG=skia:1661
R=reed@google.com
Review URL: https://codereview.chromium.org/24269006
git-svn-id: http://skia.googlecode.com/svn/trunk@11558 2bbb7eff-a529-9590-31e7-b0007b416f81
Adds a 'hasVertexCode' method to GrEffect and a 'fHasVertexCode' field
to GrGLProgramDesc::KeyHeader. Also adds a GrVertexEffect class that
effects have to inherit from in order to set the 'hasVertexCode' flag
and be able to emit vertex code, and updates the existing effects to
use it as needed.
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/23653059
git-svn-id: http://skia.googlecode.com/svn/trunk@11537 2bbb7eff-a529-9590-31e7-b0007b416f81
Extracts a GrCustomCoordsTextureEffect class from
GrSimpleTextureEffect. This way there are no effects that can
conditionally require a vertex shader. They either always need one or
never do. Also removes kCustom_CoordsType from the CoordsType enum in
GrEffect (that enum is really only meant for coords provided by the
framework), and updates GrSimpleTextureEffect::TestCreate to make the
effect with position as well, instead of just local coords.
R=bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/24018007
git-svn-id: http://skia.googlecode.com/svn/trunk@11531 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
Only affects factories, static functions that will use the factories,
and subset decoding, which all require rewinding. The decoders
themselves continue to take an SkStream. This is merely documentation
stating which functions will possibly rewind the passed in SkStream.
This is part of the general change to coordinate SkStreams with
Android's streams, which don't necessarily support rewinding in all
cases.
Update callers to use SkStreamRewindable.
BUG=skia:1572
R=bungeman@google.com, reed@google.com
Review URL: https://codereview.chromium.org/23477009
git-svn-id: http://skia.googlecode.com/svn/trunk@11460 2bbb7eff-a529-9590-31e7-b0007b416f81
