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
This path renderer converts paths to linear contours, resolves intersections via Bentley-Ottman, implements a trapezoidal decomposition a la Fournier and Montuno to produce triangles, and renders those with a single draw call. It does not currently do antialiasing, so it must be used in conjunction with multisampling.
A fair amount of the code is to handle floating point edge cases in intersections. Rather than perform exact computations (which would require arbitrary precision arithmetic), we reconnect the mesh to reflect the intersection points. For example, intersections can occur above the current vertex, and force edges to be merged into the current vertex, requiring a restart of the intersections. Splitting edges for intersections can also force them to merge with formerly-distinct edges in the same polygon, or to violate the ordering of the active edge list, or the active edge state of split edges.
BUG=skia:
Review URL: https://codereview.chromium.org/855513004
Fix path bugs exposed by the path fuzzer.
Changes to existing gm and samplecode files defer their calls to construct
SkPath objects until the first draw instead of at test initialization.
Add an experimental call to SkPath to validate the internal SkPathRef.
Fix SkPath::addPoly to set the last moveto after adding a close verb.
Fix stroke to handle failures when computing the unit normal.
Add a unit test for the unit normal failure.
R=reed@google.com
Review URL: https://codereview.chromium.org/953383002
The looper can generate more than one quad, but if any one is degenerate,
give up, but not before generating the state for the line join to
produce the correct end.
Before, the early return allowed the inside path to contain multiple
movetos that caused reversePath to assert.
R=reed@google.com
Review URL: https://codereview.chromium.org/948043002
The strokes3 test was limted to 400x800. Allow the captured gm to
go to 1500x1500, and shift it down slightly so it isn't clipped.
Review URL: https://codereview.chromium.org/945363004
Also: Add SkDeflateWStream and associated unit tests.
SkPDFBitmap is a replacement for SkPDFImage. As of now, it only
supports 8888 bitmaps (the most common case).
SkPDFBitmap takes very little extra memory (aside from refing the
bitmap's pixels), and its emitObject() does not cache any data.
The SkPDFBitmap::Create function will check the canon for duplicates.
This can reduce the size of the output PDF.
Motivation: this gives another ~40% decrease in PDF memory overhead
TODO: Support other ColorTypes and scrap SkPDFImage.
BUG=skia:3030
Review URL: https://codereview.chromium.org/918813002
Add RotateCircles3 back as better-named QuadStroker.
Switch pathfill test to call skia before draw instead of in
initializer to avoid triggering debugging breakpoints.
Review URL: https://codereview.chromium.org/912273003
There was a scaling mistake visible in some JPEG images because the ratio between Y, U and V planes were assumed to be the same ratios as the ratio between texture sizes, which was wrong because texture have a minimum size of 16 and are rounded up to the next POT. Since the ratios between Y and UV planes are generally 1, 2 or 4, rounding up to the next POT would generally preserve this ratio, so that this bug was not very visible, apart from very small jpeg images of 8 or less pixels in either width or height.
BUG=457954
Committed: https://skia.googlesource.com/skia/+/e6eddf7dd85add7da41f22f2643bdd573ad1f1cf
Review URL: https://codereview.chromium.org/922273002
Reason for revert:
Turning Windows compile bots red.
Original issue's description:
> YUV scale fix
>
> There was a scaling mistake visible in some JPEG images because the ratio between Y, U and V planes were assumed to be the same ratios as the ratio between texture sizes, which was wrong because texture have a minimum size of 16 and are rounded up to the next POT. Since the ratios between Y and UV planes are generally 1, 2 or 4, rounding up to the next POT would generally preserve this ratio, so that this bug was not very visible, apart from very small jpeg images of 8 or less pixels in either width or height.
>
> BUG=457954
>
> Committed: https://skia.googlesource.com/skia/+/e6eddf7dd85add7da41f22f2643bdd573ad1f1cfTBR=bsalomon@google.com,sugoi@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=457954
Review URL: https://codereview.chromium.org/926123002
There was a scaling mistake visible in some JPEG images because the ratio between Y, U and V planes were assumed to be the same ratios as the ratio between texture sizes, which was wrong because texture have a minimum size of 16 and are rounded up to the next POT. Since the ratios between Y and UV planes are generally 1, 2 or 4, rounding up to the next POT would generally preserve this ratio, so that this bug was not very visible, apart from very small jpeg images of 8 or less pixels in either width or height.
BUG=457954
Review URL: https://codereview.chromium.org/922273002
