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
This lets us distinguish the original ("direct") runs from their replay modes.
There was a bit of a bug in here now fixed: we used the first entry in
fSuffixes as the config. Actually, the last entry in suffixes is the
config. This is moot when there's only one suffix (direct drawing), but
for mode drawing we were recording the mode as config! Now it's correct.
Here's some example output where I rigged a bunch of modes to fail:
{
"results" : [
{
"key" : {
"config" : "565",
"mode" : "default-nobbh",
"name" : "xfermodes2"
},
"md5" : "2daf6f7e2b8e56543b92068a10d2179e",
"options" : {
"source_type" : "GM"
}
},
{
"key" : {
"config" : "8888",
"mode" : "default-nobbh",
"name" : "xfermodes2"
},
"md5" : "490361e8a52800d29558bc23876da8c6",
"options" : {
"source_type" : "GM"
}
},
...
{
"key" : {
"config" : "565",
"mode" : "direct",
"name" : "xfermodes2"
},
"md5" : "92a3801d5914d6c2662904a3bb50d2b9",
"options" : {
"source_type" : "GM"
}
},
...
{
"key" : {
"config" : "8888",
"mode" : "direct",
"name" : "xfermodes2"
},
"md5" : "e7e8b3e9d31e601acaaff4633ed5f63a",
"options" : {
"source_type" : "GM"
}
},
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/586533005
typeface. Loads the paths using the driver's glyph loading routines.
Refactors GrPathRange to accept a PathGenerator class that it uses to
lazily initialize its paths. The client code is no longer expected to
initialize the paths in a GrPathRange; instead it must provide a
PathGenerator* instance to createPathRange().
Adds a new createGlyphs() method to GrPathRendering that creates a
range of glyph paths, indexed by glyph id. GrPathRendering implements
createGlyphs() with a PathGenerator that loads glyph paths using the
skia frameworks. GrGLPathRendering uses glMemoryGlyphIndexArrayNV()
instead, when possible, to load the glyph paths.
Removes all GlyphPathRange logic from GrStencilAndCoverTextContext.
It instead uses createGlyphs().
BUG=skia:2939
R=bsalomon@google.com, jvanverth@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/563283004
This is intended to disconnect the lifetimes of the optimization data, cached layers and replacement objects.
Note that the optimization data already makes a copy of the paint in the SkPicture. Additionally the replacement object will probably go away at some point.
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/579843002
This fixes a bug where we run some Android bots with --nocpu, and the
current behavior disables the (CPU-bound) WriteTasks the GPU bound GM
runs spawn off. The WriteTasks don't run and we end up with "null" in
our .json files.
Tested locally: out/Release/dm --nocpu -w /tmp/out; ls /tmp/out
dm.json gpu/
BUG=skia:2938
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/578033002
This is a bit like a limited SkData, geared to store really tiny byte strings.
This is not hooked up anywhere beyond the new unit test. I did experimentally
plumb it into SkRecord for drawPosTextH: just over 40% of drawPosTextH calls in
our repo can fit into ShortData.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/573323002