Underscore is used as a field separator sometimes when parsing the task
name into a list of config, mode, etc. (This itself is dumb and TODO(mtklein): fix.)
Underscores in the field names will really mess that up, both in directories generated
from human-mode -w, and in the .json file.
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/599503002
If a font is bitmap only we need to scale a bitmap to obtain
the requested size if there isn't an exact match. If a font has
embedded bitmaps then these bitmaps should never be scaled by Skia.
Allow FreeType to do the scaling (as requested by the font).
BUG=chromium:408059
R=mtklein@google.com
Author: bungeman@google.com
Review URL: https://codereview.chromium.org/596513002
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
