| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
BUG=skia:3739
Review URL: https://codereview.chromium.org/1094863003
|
|
|
|
|
|
| |
BUG=skia:3735
Review URL: https://codereview.chromium.org/1097433002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1097443002
|
|
|
|
|
|
| |
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1086203002
|
|
|
|
|
|
| |
BUG=chromium:473156
Review URL: https://codereview.chromium.org/1089063002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1085443005
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1076593002
|
|
|
|
|
|
|
|
| |
High quality anisotropic is an interesting edge case for the gpu backend. For scales that are both minimizing and maximizing Ganesh falls back to MipMaps which can turn out too blurry.
BUG=472864
Review URL: https://codereview.chromium.org/1058133003
|
|
|
|
|
|
| |
BUG=470083
Review URL: https://codereview.chromium.org/1081173002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1085453002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1079813002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1067853002
|
|
|
|
|
|
|
|
| |
N.B.: this will change results on the bots for all the tests modified.
BUG=skia:3319
Review URL: https://codereview.chromium.org/1077763002
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, GM's are now being composited against white
in some modes, where the alpha used to be ignored (or composited
against black, I'm not sure which). At any rate, it doesn't
make much sense to have alpha in the result anyway, so let's clear to
opaque black instead of transparent black and avoid the problem.
This is a trial balloon for bitmapsource and pictureimagefilter.
If all goes well, I'll make this change more widely.
R=scroggo
BUG=skia:3319
Review URL: https://codereview.chromium.org/1074513002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1031423002
|
|
|
|
|
|
| |
Committed: https://skia.googlesource.com/skia/+/dfbbec436cbcacc3270d4b28357c8393e67d6494
Review URL: https://codereview.chromium.org/978713002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/978713002/)
Reason for revert:
Revert while investigating assertions.
Original issue's description:
> Add constant color GrFP.
>
> Committed: https://skia.googlesource.com/skia/+/dfbbec436cbcacc3270d4b28357c8393e67d6494
TBR=egdaniel@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1055023002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1052083004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter, SkMatrixConvolutionImageFilter,
SkMatrixImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
For the SkMatrixConvolutionImageFilter, it seems the
GLSL clamp() function occasionally returns values outside
the clamped range, resulting in access of garbage
texels even in GL_NEAREST. The fix here is to clamp to a
rect inset by half a texel. There was also a bug in
the unpremultiply step when fConvolveAlpha is false.
For SkMatrixImageFilter, the fix was to make the generic
draw path be more careful about when to use texture domain.
If the bitmap already has a texture, use texture domain
if the srcRect is smaller than the entire texture (not
the entire bitmap).
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c
Review URL: https://codereview.chromium.org/1034733002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offscreen. (patchset #31 id:590001 of https://codereview.chromium.org/1034733002/)
Reason for revert:
Spoke to Stephen about this. Reverting because failing debug builds:
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Mac10.9-Clang-MacMini6.2-GPU-HD4000-x86_64-Debug/builds/51
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/54
Original issue's description:
> Implement approx-match support in image filter saveLayer() offscreen.
>
> Currently, the GPU-side image filter implementation creates
> exact-match textures for the offscreen backing stores for
> saveLayer(). This is because several filters have GPU
> implementations which depend on the texture coordinates
> being 0..1.
>
> The fix is three-fold:
>
> 1) Store the actual requested size in the SkGpuDevice, so
> that when wrapping it in an SkBitmap for passing to
> filterImage(), we can give it the original size.
> 2) Fix the filters (SkMagnifierImageFilter,
> SkLightingImageFilter, SkMatrixConvolutionImageFilter,
> SkMatrixImageFilter) whose GPU implementation depends on
> 0..1 texture coordinates.
> 3) Remove the exception for GPU-side image filters in
> SkCanvas::internalSaveLayer().
>
> For the lighting filters, there were two bugs which were
> cancelling each other out: the sobel filter matrix was
> being computed upside down, but then we'd negate the
> resulting normal. This worked fine in the exact-match case,
> but in the approx-match case we'd sample garbage along
> the edge pixels. Also, we never implemented the edge pixels
> according to spec in the GPU case. It requires a
> different fragment shader for each edge of the nine-patch,
> which meant we couldn't use asFragmentProcessor(), and had
> to implement the drawing via a filterImageGPU() override.
> In order to avoid polluting the public API, I inserted a
> new base class, SkLightingImageFilterInternal above
> Sk[Diffuse|Specular]LightingImageFilter to handle the
> implementation.
>
> For the SkMatrixConvolutionImageFilter, it seems the
> GLSL clamp() function occasionally returns values outside
> the clamped range, resulting in access of garbage
> texels even in GL_NEAREST. The fix here is to clamp to a
> rect inset by half a texel. There was also a bug in
> the unpremultiply step when fConvolveAlpha is false.
>
> For SkMatrixImageFilter, the fix was to make the generic
> draw path be more careful about when to use texture domain.
> If the bitmap already has a texture, use texture domain
> if the srcRect is smaller than the entire texture (not
> the entire bitmap).
>
> N.B.: this change will cause some minor pixel diffs in the
> GPU results of the following GMs (and possibly more):
> matriximagefilter, matrixconvolution, imagefiltersscaled,
> lighting, imagemagnifier, filterfastbounds,
> complexclip_aa_Layer_invert, complexclip_aa_layer,
> complexclip_bw_layer_invert, complexclip_bw_layer.
>
> BUG=skia:3532
>
> Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
>
> Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
>
> Committed: https://skia.googlesource.com/skia/+/46112cf2a7c7307f1c9eebb5f881cbda15aa460c
TBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057693002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/978713002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter, SkMatrixConvolutionImageFilter,
SkMatrixImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
For the SkMatrixConvolutionImageFilter, it seems the
GLSL clamp() function occasionally returns values outside
the clamped range, resulting in access of garbage
texels even in GL_NEAREST. The fix here is to clamp to a
rect inset by half a texel. There was also a bug in
the unpremultiply step when fConvolveAlpha is false.
For SkMatrixImageFilter, the fix was to make the generic
draw path be more careful about when to use texture domain.
If the bitmap already has a texture, use texture domain
if the srcRect is smaller than the entire texture (not
the entire bitmap).
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
Review URL: https://codereview.chromium.org/1034733002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offscreen. (patchset #27 id:510001 of https://codereview.chromium.org/1034733002/)
Reason for revert:
Looks like this change is causing layout test failures which is blocking Skia's DEPS roll into Chromium:
https://codereview.chromium.org/1050563002/
https://codereview.chromium.org/1043133005/
https://codereview.chromium.org/1048273002/
Reverting to see if this fixes the DEPS roll.
Original issue's description:
> Implement approx-match support in image filter saveLayer() offscreen.
>
> Currently, the GPU-side image filter implementation creates
> exact-match textures for the offscreen backing stores for
> saveLayer(). This is because several filters have GPU
> implementations which depend on the texture coordinates
> being 0..1.
>
> The fix is three-fold:
>
> 1) Store the actual requested size in the SkGpuDevice, so
> that when wrapping it in an SkBitmap for passing to
> filterImage(), we can give it the original size.
> 2) Fix the filters (SkMagnifierImageFilter,
> SkLightingImageFilter) whose GPU implementation depends on
> 0..1 texture coordinates.
> 3) Remove the exception for GPU-side image filters in
> SkCanvas::internalSaveLayer().
>
> For the lighting filters, there were two bugs which were
> cancelling each other out: the sobel filter matrix was
> being computed upside down, but then we'd negate the
> resulting normal. This worked fine in the exact-match case,
> but in the approx-match case we'd sample garbage along
> the edge pixels. Also, we never implemented the edge pixels
> according to spec in the GPU case. It requires a
> different fragment shader for each edge of the nine-patch,
> which meant we couldn't use asFragmentProcessor(), and had
> to implement the drawing via a filterImageGPU() override.
> In order to avoid polluting the public API, I inserted a
> new base class, SkLightingImageFilterInternal above
> Sk[Diffuse|Specular]LightingImageFilter to handle the
> implementation.
>
> N.B.: this change will cause some minor pixel diffs in the
> GPU results of the following GMs (and possibly more):
> matriximagefilter, matrixconvolution, imagefiltersscaled,
> lighting, imagemagnifier, filterfastbounds,
> complexclip_aa_Layer_invert, complexclip_aa_layer,
> complexclip_bw_layer_invert, complexclip_bw_layer.
>
> BUG=skia:3532
>
> Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
>
> Committed: https://skia.googlesource.com/skia/+/f5f8518fe0bbd2703e4ffc1b11ad7b4312ff7641
TBR=bsalomon@google.com,reed@chromium.org,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3532
Review URL: https://codereview.chromium.org/1057443003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the GPU-side image filter implementation creates
exact-match textures for the offscreen backing stores for
saveLayer(). This is because several filters have GPU
implementations which depend on the texture coordinates
being 0..1.
The fix is three-fold:
1) Store the actual requested size in the SkGpuDevice, so
that when wrapping it in an SkBitmap for passing to
filterImage(), we can give it the original size.
2) Fix the filters (SkMagnifierImageFilter,
SkLightingImageFilter) whose GPU implementation depends on
0..1 texture coordinates.
3) Remove the exception for GPU-side image filters in
SkCanvas::internalSaveLayer().
For the lighting filters, there were two bugs which were
cancelling each other out: the sobel filter matrix was
being computed upside down, but then we'd negate the
resulting normal. This worked fine in the exact-match case,
but in the approx-match case we'd sample garbage along
the edge pixels. Also, we never implemented the edge pixels
according to spec in the GPU case. It requires a
different fragment shader for each edge of the nine-patch,
which meant we couldn't use asFragmentProcessor(), and had
to implement the drawing via a filterImageGPU() override.
In order to avoid polluting the public API, I inserted a
new base class, SkLightingImageFilterInternal above
Sk[Diffuse|Specular]LightingImageFilter to handle the
implementation.
N.B.: this change will cause some minor pixel diffs in the
GPU results of the following GMs (and possibly more):
matriximagefilter, matrixconvolution, imagefiltersscaled,
lighting, imagemagnifier, filterfastbounds,
complexclip_aa_Layer_invert, complexclip_aa_layer,
complexclip_bw_layer_invert, complexclip_bw_layer.
BUG=skia:3532
Committed: https://skia.googlesource.com/skia/+/b97dafefe63ea0a1bbce8e8b209f4920983fb8b9
Review URL: https://codereview.chromium.org/1034733002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1041913002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1041773003
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1034273002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
NOPRESUBMIT=true
BUG=skia:
DOCS_PREVIEW= https://skia.org/?cl=1037793002
Review URL: https://codereview.chromium.org/1037793002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/967943002/)"
disabled for the momment -- need to understand arm64 glitches
This reverts commit 374a4c3b744e8c77455efa73b139950136f7b374.
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1028403002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/967943002/)
Reason for revert:
Arm64 seems to be having glitches :(
See gm:colormatrix on Arm64/TegraK1/Nexus9
last square should be all white, but it has stripes
Original issue's description:
> impl colormatrix w/ floats
>
> this needs to land first https://codereview.chromium.org/1031713003
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/7971def11be91ed08eae7107b372322d24e67544
TBR=mtklein@google.com,caryclark@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1030743003
|
|
|
|
|
|
|
|
| |
this needs to land first https://codereview.chromium.org/1031713003
BUG=skia:
Review URL: https://codereview.chromium.org/967943002
|
|
|
|
|
|
| |
Without this CL, saving a revised skp out the debugger can greatly expand the memory it requires.
Review URL: https://codereview.chromium.org/1020103005
|
|
|
|
|
|
|
|
| |
Add a GM.
BUG=skia:255
Review URL: https://codereview.chromium.org/950633003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/950633003/)
Reason for revert:
static void draw(SkCanvas* canvas,
const SkPaint& p,
const SkBitmap& src,
SkColorType colorType,
const char text[]) {
SkASSERT(src.colorType() == colorType);
canvas->drawBitmap(src, 0.0f, 0.0f);
canvas->drawText(text, strlen(text), 0.0f, 12.0f, p);
}
This assert is firing, at least on macs, where all images get decoded into 32bit at the moment.
Original issue's description:
> PDF: remove last use of SkPDFImage
>
> Add a GM.
>
> BUG=skia:255
>
> Committed: https://skia.googlesource.com/skia/+/86ad8d643624a55b02e529100bbe4e2940115fa1
TBR=mtklein@google.com,halcanary@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:255
Review URL: https://codereview.chromium.org/1024113002
|
|
|
|
|
|
|
|
| |
Add a GM.
BUG=skia:255
Review URL: https://codereview.chromium.org/950633003
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1028663002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1011273003
|
|
|
|
|
|
|
|
| |
BUG=468311
see also skiabug.com/3567
Review URL: https://codereview.chromium.org/1002603003
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
|
|
|
|
|
|
|
|
| |
patch from issue 1014783003 at patchset 60001 (http://crrev.com/1014783003#ps60001)
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1010343002
|
|
|
|
|
|
|
|
|
| |
Need to check for zero-length gradients when using the new correction.
Make sure we use the old text sizes for color emoji test in dftext GM.
BUG=skia:3540
Review URL: https://codereview.chromium.org/1009973004
|
|
|
|
|
|
|
|
| |
Also adds two non-uniform test cases to the dftext GM.
BUG=skia:3540
Review URL: https://codereview.chromium.org/1013773002
|
|
|
|
|
|
|
|
|
| |
clone (+rebase) of https://codereview.chromium.org/1009183002/
BUG=skia:
TBR=scroggo@google.com
Review URL: https://codereview.chromium.org/1014533004
|
|
|
|
|
|
|
|
|
| |
If SkDrawFilter is working, they will not match (have different colors
and one will be blurred). If SkDrawFilter is broken, they will match.
R=scroggo@google.com
Review URL: https://codereview.chromium.org/984883003
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/979343002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The core of the problem is that the system is asked to lookup the metrics for a character with id == 0. This causes a hit in the fCharToGlyphHash matching the sentinel glyph. This happens because fCharToGlpyhHash is initialized with all zeros, therefore, the fID is zero matching the char with id == 0. The fAdvanceX field of the sentinel glyph is in fact not initialized.
The bigger question is now did a zero character get passed to getUnicharMetrics?
The breaking code is basically as follows:
wchar_t glyph = L'S';
paint.measureText(&glyph, 2);
This get mischaracterized as a utf8 string instead of a utf16(?) string. Because of the little endian ordering, this is the character string 'L' '\0'. Since the size of the original string is two bytes (but a single character) the '\0' is treated as its own character and past to getUnicharMetrics.
TEST:
On windows failed using DrMemory. With this change does not fail.
BUG=463204
Review URL: https://codereview.chromium.org/977063002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/973593002
|
|
|
|
|
|
|
|
|
|
|
| |
now with serialization registration
This reverts commit 5bd055c0386499f2dc8c66173a7534b75af602bf.
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/970753002
|