Allow GM results to be compared across machines and platforms by
standardizing the fonts used by all tests.
This adds runtime flags to DM to use either the system font context (the
default), the fonts in the resources directory ( --resourceFonts ) or a set
of canonical paths generated from the fonts ( --portableFonts ).
This CL should leave the current DM results unchanged by default.
If the portable font data or resource font is missing when DM is run, it
falls back to using the system font context.
The create_test_font tool generates the paths and metrics read by DM
with the --portableFonts flag set, and generates the font substitution
tables read by DM with the --resourceFonts flag set.
If DM is run in SkDebug mode with the --reportUsedChars flag set, it
generates the corresponding data compiled into the create_test_font tool.
All GM tests set their typeface information by calling either
sk_tool_utils::set_portable_typeface or
sk_tool_utils::portable_typeface .
(The former takes the paint, the latter returns a SkTypeface.) These calls
can be removed in the future when the Font Manager can be superceded.
BUG=skia:2687
R=mtklein@google.com
Review URL: https://codereview.chromium.org/407183003
The recorder optimizer's pattern matcher was accepting command sequences
when it shouldn't have.
In the submitted case, and the pattern matcher was looking for:
saveLayer, drawBitmap, restore
and in the rendering for the submitted case, the sequence of commands
were:
saveLayer, drawBitmap, drawBitmap, restore
This sequence was improperly accepted by the matcher, and the optimizer
reduced the sequence to:
drawBitmap, drawBitmap
where the opacity from the saveLayer paint argument was applied
to the first drawBitmap only.
The user-visible effect in Chrome was a flashing effect on an image
caused by incorrect (too-high) opacity.
The patch adds a Skia test to check for pixel colour values in
a similarly structured recording. All other Skia tests pass.
Blink layout tests also pass with this change.
BUG=chromium:344987
R=robertphillips@google.com, reed@google.com, mtklein@google.com
Author: dneto@chromium.org
Review URL: https://codereview.chromium.org/430503004
Add a unique ID to SkImageFilter, and use it as part
of a persistent cache of image-filtered results. This is used for
caching frame-to-frame coherent filters.
We also keep track of which filter subtrees do not reference the
src input, and use a GenID of zero for the src input in that case.
That way, subtrees which are not dependent on the filter input can be
cached independently of it.
This gives approximately a 4X speedup on
letmespellitoutforyou.com/samples/svg/filter_terrain.svg on Z620
and Nexus10. The cache key consists of the uniqueID of the filter, the
clip bounds, the CTM and the genID of the input bitmap.
Since this does not yet handle the case where the input primitives
(and part of the resulting filter tree) are unchanged, we have
to keep around the external cache for that painting case.
When the work to cache unchanging input primitives is done, the
old cache can be removed, and the new UniqueIDCache will be renamed
to Cache.
R=bsalomon@google.com, mtklein@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/414483003
https://codereview.chromium.org/283093002 fixed some bugs in pipe memory
allocation, but also introduced one of its own: nearly every block requested
from needOpBytes() got its own 16K allocation.
The correct logic is to take the requested size, add four more bytes for a
DrawOp, make sure that's 4-byte aligned, then check to see if there's enough
space for that in the current block. If there's not, allocate at least
MIN_BLOCK_SIZE bytes to fit the request.
The bug is that I moved that round-up-to-MIN_BLOCK_SIZE step before checking
for space in the current block. This means most (all?) blocks will be 16K but
never seem to have room to fit another allocation. You need 8 bytes? You get
16K. You need 8 more bytes? Nope, can't fit that. Here's a new 16K...
This reverts the change to the test I made then, which really should have
tipped me off. It was testing exactly this bug.
BUG=372671
R=tomhudson@chromium.org, tomhudson@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/433463003
Adds the glStencilThenCover* nvpr methods to GrGLInterface and starts
using them. When drawing multible paths, this will make it so we only
have to send the index/transform data once. It will also allow the
driver to save time internally.
The glStencilThenCover* methods are a newer addition, so they aren't
available on every driver. In the event that they are not present, we
emulate them using the existing glStencil*/glCover* methods.
BUG=skia:
R=markkilgard@gmail.com, bsalomon@google.com
Author: cdalton@nvidia.com
Review URL: https://codereview.chromium.org/423173004
