It's super tedious to keep setting it every time I rerun ./gyp_skia.
Doesn't look like it'll bother the bots.
BUG=skia:
Review URL: https://codereview.chromium.org/1053493005
(We never set arm_version = 7 for iOS...)
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/1092753002
Currently there exist SkScalarPin and SkPin32, and in a future change
another version is desired. This change introduces SkTPin and changes
SkScalarPin and SkPin32 to use it.
Review URL: https://codereview.chromium.org/1090003002
With dashed paths, we get a lot of geometry on the same sort line.
Since the vertices are sorted, it makes more sense to insert edges
from the end (in sort order) than the beginning. This requires
maintaining both the head and tail of the active edge list.
This gives a ~20% perf improvement on tabl_digg.skp.
BUG=skia:3733
Review URL: https://codereview.chromium.org/1089903002
Memory will be overwritten while downsampling some
interlaced gif images, most commonly with odd sizes,
when index of destination row stores in the current
line computed from GifInterlaceIter meets:
X is an integer in [0..height-1]
and
(X < height)
&& ((X - sampleSize/2) % sampleSize == 0)
&& ((X - sampleSize/2)/sampleSize >= height/sampleSize)
Signed-off-by: Lu Tong <lu.x.tong@sonymobile.com>
BUG=skia:
Review URL: https://codereview.chromium.org/1085253002
The dFdy(st.y) computation seems to be better than the dFdx(st.x) computation
on the Mali, so using that. The end result should be about the same.
BUG=skia:3528
Review URL: https://codereview.chromium.org/1082913006
The tessellating path renderer uses several sweep-line algorithms,
whose sweep direction can be either in X or Y.
It is currently set to in-X at compile time, but a better approach is to
make it runtime-configurable, and use the path aspect ratio as
a heuristic to determine the optimal sweep direction.
BUG=skia:3725
Review URL: https://codereview.chromium.org/1089073002
Enables basic decoding for jpegs
Includes rewinding
565, YUV, and Jpeg encoding are not yet implemented
BUG=skia:3257
Review URL: https://codereview.chromium.org/1076923002
cropBitmap returns 'true' on success and 'false' on failure.
Propagate its return value so that cascading failures can be avoided.
Signed-off-by: Mykola Kondratenko <mykola.kondratenko@sonymobile.com>
BUG=skia:
Review URL: https://codereview.chromium.org/1088093003
Motivation: I want to switch back to single-page output by default for
direct comparison to raster backends in Gold.
I can still test the multi-page option via a command-line switch.
BUG=skia:3721
Review URL: https://codereview.chromium.org/1063873004
These will underly the SkPMFloat-like class for uint16_t components.
Sk4h will back a single-pixel version, and Sk8h any larger number than that.
BUG=skia:
Review URL: https://codereview.chromium.org/1088883005
As used today, SkNi is used in bool-y contexts. This keeps that, but under a
new name, SkNb. This makes room for a new SkNi that's focused on integer-y
things like loads, stores, arithmetic, etc.
The main reason to split these is that we want different specializations for
each use case: for bools, it's important for us to specialize 32- and 64-bit to
support efficient float- and double- comparisons, but for integer work we're
more likely to be looking at 8- and 16- bit lanes. Keeping these use cases
siloed helps me manage the compexity of the backend NEON and SSE code.
BUG=skia:
Review URL: https://codereview.chromium.org/1083123002
High quality anisotropic is an interesting edge case for the gpu backend. For scales that are both minimizing and maximizing Ganesh falls back to MipMaps which can turn out too blurry.
BUG=472864
Review URL: https://codereview.chromium.org/1058133003
This also contains a fix to remove recursion from the sorted_merge()
step. This was essentially tail-recursion, and was causing stack
exhaustion on some platforms. Making it iterative fixes the issue.
Note: this CL will affect a large number of GPU GM results.
R=bsalomon@google.com
BUG=
Review URL: https://codereview.chromium.org/1080113004
When an SkRecord has more than kInlineRecords ops in it (today, 5 or more), the
current logic undercounts the bytes used by the SkRecord by sizeof(Record) *
kInlineRecords, i.e. 32 bytes. This isn't a huge deal... by the time you've
recorded 5 ops, we're typically up around 1KB anyway, and it's only ever off by
that constant 32 bytes, so somewhere between 3% to 0% error as the picture grows.
But now that I've noticed, we might as well fix it. Basically, this is a
reminder that the inline space used to store those first kInlineRecords ops
goes to waste once we pass that threshold. In contrast, fInlineAlloc, the
space we preallocate for the SkVarAlloc, never goes to waste. It always holds
the first few ops' data even when we grow past it.
BUG=skia:
Review URL: https://codereview.chromium.org/1081433002
