This reverts commit 2a2f675926.
Reason for revert: this appears to be what is holding up the Chrome roll.
Original change's description:
> SkTypes: extract SkTo
>
> Change-Id: I8de790d5013db2105ad885fa2683303d7c250b09
> Reviewed-on: https://skia-review.googlesource.com/133620
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,halcanary@google.com
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Iafd738aedfb679a23c061a51afe4b98a8d4cdfae
Reviewed-on: https://skia-review.googlesource.com/134504
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
This is a reland of c86c5c0144
Original change's description:
> Remove devKerning
>
> Dev kerning is not supported by any scalers. This is
> mostly removed. The remaining fields fRsbDelta and
> fLsbDelta are kept to keep Android compiling.
>
> Change-Id: If1a9ee9bb599d4e1bdf4b3751ac0c65246350809
> Reviewed-on: https://skia-review.googlesource.com/124921
> Reviewed-by: Ben Wagner <bungeman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
Change-Id: Ibf5fac5f1442c7e62392d5146ad460da27b10d5c
Reviewed-on: https://skia-review.googlesource.com/125300
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This reverts commit c86c5c0144.
Reason for revert: 4 of 5
Original change's description:
> Remove devKerning
>
> Dev kerning is not supported by any scalers. This is
> mostly removed. The remaining fields fRsbDelta and
> fLsbDelta are kept to keep Android compiling.
>
> Change-Id: If1a9ee9bb599d4e1bdf4b3751ac0c65246350809
> Reviewed-on: https://skia-review.googlesource.com/124921
> Reviewed-by: Ben Wagner <bungeman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
TBR=bungeman@google.com,herb@google.com,reed@google.com
Change-Id: If865f702868192a1b72cd811baa996dd1282bbce
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/125263
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Dev kerning is not supported by any scalers. This is
mostly removed. The remaining fields fRsbDelta and
fLsbDelta are kept to keep Android compiling.
Change-Id: If1a9ee9bb599d4e1bdf4b3751ac0c65246350809
Reviewed-on: https://skia-review.googlesource.com/124921
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
The original intent of this flag is now handled by SkPixelGeomety on
SkSurfaceProps on SkSurface.
BUG=skia:7515
Change-Id: I54bb1be072b5b5b2164a59196bfeacac254823c7
Reviewed-on: https://skia-review.googlesource.com/121346
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This reverts commit 1a104bce20.
Change (from first version) is
- only signal error in readbuffer for corrupt stream, not default fonts
- change test to ensure a non-null typeface (i.e. MakeDefault())
Bug: skia:
Change-Id: I325445b56b0a402e1b89a2439df06e92314c793f
Reviewed-on: https://skia-review.googlesource.com/82687
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
SkFAIL is a legacy macro which is just SK_ABORT. This CL mechanically
changes uses of SkFAIL to SK_ABORT in preparation for its removal. The
related sk_throw macro will be changed independently, due to needing to
actually clean up its users.
Change-Id: Id70b5c111a02d2458dc60c8933f444df27d9cebb
Reviewed-on: https://skia-review.googlesource.com/35284
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
If the bounds of the blob are empty, we will request a zero-sized surface
which will fail. Just check for that.
Only expect this if the typeface is empty (e.g. faked out for testing)
Bug: skia:
Change-Id: Idcac0e9d4e2a5fe68926a33250015609b5c7e365
Reviewed-on: https://skia-review.googlesource.com/22360
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
We can flag the last run record instead. Run iteration is always
sequential, so no penalty.
As a side effect, we can no longer allow instantiation of zero-run text
blobs - but that seems like a good idea anyway.
Change-Id: I7ca80c4780623d5a188f92dfe6d6fe152f20f666
Reviewed-on: https://skia-review.googlesource.com/9149
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
android now updated.
This reverts commit e005edd3a5.
BUG=skia:6250
Change-Id: If08d344cdd863fde1d9955dc3fab671a83be0f73
Reviewed-on: https://skia-review.googlesource.com/8815
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Motivation: This will be easier than adding a friend every time I want
to create a one-off SkCanvas subclass or SkRemote::Encoder subclass.
See also: SkPath::Iter.
Review URL: https://codereview.chromium.org/1411723005
At the end of TightRunBounds, glyphPosX cannot exceed the start of the
next run. But glyphPosY is running ahead of glyphPosX (for
kFull_Positioning) => the glyphPosY assert is incorrect.
Since the two pointers advance in lock-step, there isn't much value in
the glyphPosY assert anyway - we might as well remove it.
BUG=chromium:542643
R=reed@google.com,bungeman@google.com
Review URL: https://codereview.chromium.org/1405463004
Refactored text blob backend for improved performance: instead of using
separate buffers for runs/positions/glyphs, everything is now packed in
a consolidated slab (including the SkTextBlob object itself!).
Benefits:
* number of allocations per blob construction reduced from ~4 to 1
(also minimizes internal fragmentation)
* run record size reduced by 8 bytes
This takes the blob construction overhead down to negligible levels
(for the current Blink uncached textblob implementation).
Unfortunately, the code is much more finicky (run merging in
particular) -- hence the assert spree.
Multi-run blobs are vulnerable to realloc storms but this is not a
problem at the moment because Blink is using one-run blobs 99% of the
time. Will be addressed in the future.
R=mtklein@google.com, reed@google.com, robertphillips@google.com
Committed: https://skia.googlesource.com/skia/+/13645ea0ea87038ebd71be3bd6d53b313069a9e4
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/581173003
Reason for revert:
Broke the new blobshader gm.
Original issue's description:
> Souped-up SkTextBlob.
>
> Refactored text blob backend for improved performance: instead of using
> separate buffers for runs/positions/glyphs, everything is now packed in
> a consolidated slab (including the SkTextBlob object itself!).
>
> Benefits:
>
> * number of allocations per blob construction reduced from ~4 to 1
> (also minimizes internal fragmentation)
> * run record size reduced by 8 bytes
>
> This takes the blob construction overhead down to negligible levels
> (for the current Blink uncached textblob implementation).
>
> Unfortunately, the code is much more finicky (run merging in
> particular) -- hence the assert spree.
>
> Multi-run blobs are vulnerable to realloc storms but this is not a
> problem at the moment because Blink is using one-run blobs 99% of the
> time. Will be addressed in the future.
>
>
> R=reed@google.com,mtklein@google.com,robertphillips@google.com
>
> Committed: https://skia.googlesource.com/skia/+/13645ea0ea87038ebd71be3bd6d53b313069a9e4R=mtklein@google.com, reed@google.com, robertphillips@google.comTBR=mtklein@google.com, reed@google.com, robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/588853002
Refactored text blob backend for improved performance: instead of using
separate buffers for runs/positions/glyphs, everything is now packed in
a consolidated slab (including the SkTextBlob object itself!).
Benefits:
* number of allocations per blob construction reduced from ~4 to 1
(also minimizes internal fragmentation)
* run record size reduced by 8 bytes
This takes the blob construction overhead down to negligible levels
(for the current Blink uncached textblob implementation).
Unfortunately, the code is much more finicky (run merging in
particular) -- hence the assert spree.
Multi-run blobs are vulnerable to realloc storms but this is not a
problem at the moment because Blink is using one-run blobs 99% of the
time. Will be addressed in the future.
R=mtklein@google.com, reed@google.com, robertphillips@google.com
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/581173003
