The entire text content of the 'font' element is currently used as the
file name. This wasn't an issue in earlier versions, as the 'file'
element was dedicated to only containing the file name. The new 'font'
element also contains a number of attributes and potentially other tags.
This means that a 'font' element can become quite long, making it
desireable to be able to split it across multiple lines.
However, splitting the 'font' element across multiple lines is currently
difficult and awkward as any whitespace outside of tags will be
considered part of the file name. This change means that any leading or
trailing whitespace will not be considered part of the file name.
This only applies to v21 and later files, so while this restricts font
file names from beginning and ending with whitespace, it is unlikely to
break any users in practice. It is probably also undesireable to have
font files with names that begin or end with whitespace in any event.
Review URL: https://codereview.chromium.org/1125413003
Reason for revert:
speculative revert to fix failures in DEPS roll
Original issue's description:
> Sketch splitting SkPicture into an interface and SkBigPicture.
>
> Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
> These cover about 89% of draw calls from Blink SKPs,
> and about 25% of draw calls from our GMs.
>
> SkPicture handles:
> - serialization and deserialization
> - unique IDs
>
> Everything else is left to the subclasses:
> - playback(), cullRect()
> - hasBitmap(), hasText(), suitableForGPU(), etc.
> - LayerInfo / AccelData if applicable.
>
> The time to record a 1-op picture improves a good chunk
> (2 mallocs to 1), and the time to record a 0-op picture
> greatly improves (2 mallocs to none):
>
> picture_overhead_draw: 450ns -> 350ns
> picture_overhead_nodraw: 300ns -> 90ns
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/c92c129ff85b05a714bd1bf921c02d5e14651f8bTBR=reed@google.com,robertphillips@google.com,mtklein@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1130333002
Adds small pictures for drawRect(), drawTextBlob(), and drawPath().
These cover about 89% of draw calls from Blink SKPs,
and about 25% of draw calls from our GMs.
SkPicture handles:
- serialization and deserialization
- unique IDs
Everything else is left to the subclasses:
- playback(), cullRect()
- hasBitmap(), hasText(), suitableForGPU(), etc.
- LayerInfo / AccelData if applicable.
The time to record a 1-op picture improves a good chunk
(2 mallocs to 1), and the time to record a 0-op picture
greatly improves (2 mallocs to none):
picture_overhead_draw: 450ns -> 350ns
picture_overhead_nodraw: 300ns -> 90ns
BUG=skia:
Review URL: https://codereview.chromium.org/1112523006
Currently SampleApp on Android cannot find resources. This sets the
resourcePath to /data/local/tmp/skia/resources/ which is the path
used in documentationo. A future change will allow this default to be
overridden.
BUG=skia:3815
Review URL: https://codereview.chromium.org/1125363004
Previously it was hard to tell that DrawFn took an SkCanvas* and returned an Error. Now it's clear from the type.
BUG=skia:
Review URL: https://codereview.chromium.org/1125233002
This CL refactors the location of the GrBufferAllocPools so they reside entirely inside the GrBatchTarget. This is in preparation for making them use scratch resources.
Review URL: https://codereview.chromium.org/1131553002
We don't seem to be making good use of the available instruction set.
SSE4.1 gives us an easy way to unpack a pixel into an __m128i, and
SSSE3 gave us an easy way to do the reverse.
This should be bit-perfect and about a 10% speedup.
BUG=skia:
Review URL: https://codereview.chromium.org/1123263003
I'm thinking of using this in perf with something like:
ratio(fill(filter("test=foo")), fill(filter("test=control")))
Does that make sense to you?
Not sure that this is really a good control bench on all bots,
but I propose we just run it a bit and find out if it needs work.
BUG=skia:
Review URL: https://codereview.chromium.org/1129823003
If so, let's do it this way so it works for all source types and doesn't need
to be chosen at compile time.
BUG=skia:
Review URL: https://codereview.chromium.org/1129693003
The Android bots are flaking like crazy. I'm not sure if these configs
are hurting the situation, but let's see if this helps.
TBR=mtklein,halcanary
BUG=skia:
Review URL: https://codereview.chromium.org/1131603002
This totally overhauls the implementation to use ordinary inheritance-based type erasure. I give up for now getting my manual vtable shenanigans to work with MSVC. Still those same "expected ; before ), also expected ) before ;" errors.
I added support for uninitialized SkFunctions and operator=(), because it was fairly straightforward with this implementation.
The main downside here is that I've removed the inline implementation. All SkFunctions involve a heap allocation, even when just wrapping function pointers.
BUG=skia:
Review URL: https://codereview.chromium.org/1056673002
This utility class is going to be revamped and moved. This CL shrinks it a bit so there will be less to shuffle around.
Review URL: https://codereview.chromium.org/1126753003
Will use this to test the other CL that adds small SkPicture implementations.
Not quite sure why patch_primitive doesn't draw the same in 8888 and sp-8888, but everything else does, so I'm not going to let that hold me back for now.
BUG=skia:
Review URL: https://codereview.chromium.org/1126613005
