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
