The previous change to atlas sizes introduced an issue where texture
coordinates for glyphs stored on the right side of the atlas were being
computed in an imprecise manner on Mali400 chips.
The only reasonable fix appears to be to use power-of-two texture sizes.
This widens the glyph atlas to the next power of 2 (or 2048) for A8 glyphs
only, and widens each GrPlot by 2x as well. By doing this, we can fit 3-4 large
distance field glyphs into a single GrPlot, which gives us 100-128 total large
glyphs at one time.
The 565 and 8888 glyph atlases are kept in their original size to preserve
space.
BUG=skia:3523
Review URL: https://codereview.chromium.org/994303003
The colors seen in the overdraw color filter are not guaranteed to remain the colors from its own table. Looping through the table to find the old overdraw level is error prone and expensive.
Review URL: https://codereview.chromium.org/997913002
Before the fix, we could use a stale cache of the clipbounds in quickReject. Often this could return false negatives, meaning we would try to draw more than we should (it would eventually be really clipped). Occasionally this could also report false positives (if the layer were outside of the normal canvas bounds, e.g. a layer with an offset imagefilter).
BUG=skia:
NOTREECHECKS=True
Review URL: https://codereview.chromium.org/983243003
In non-verbose mode, these notes will spin away too fast to read anyway,
unless they're so long they end up leaving junk on the terminal.
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/989083002
'GPU' is in 'Test-Ubuntu14-GCE-NoGPU-x86_64-Release-Valgrind_CPU' too.
This means we're building it in no-GPU mode, and running it in no-CPU mode.
At least it finishes quite quickly this way (~10 seconds).
BUG=skia:
Review URL: https://codereview.chromium.org/992203004
Pictures with many drawn paths benefit from the increase of the
count. As an example, chalkboard testcase has ~2500 paths, tiger
has ~300.
Bigger objects, like textures, tend to be limited by the cache
byte limit, not item count.
Review URL: https://codereview.chromium.org/991783003
This changes SkScalarClampMax and SkScalarPin to use SkTMin and SkTMax.
This change allows compilers to more easily transform these operations
into fast max/min operarations as opposed to conditional branches.
Review URL: https://codereview.chromium.org/993593002
Reason for revert:
There's some weirdness with Tegra2 and Tegra3 GMs (Xoom and Nexus7) that may be related to this.
Original issue's description:
> Adjust distance field glyph and font atlas sizes to maximize storage.
>
> Because of high DPI devices, we need more room in the glyph
> atlas for the larger glyphs. These settings will allow 4 of
> the distance field glyphs to fit in one Plot (increasing
> the storage from 32 large glyphs to 128), and still permit
> us to handle glyphs up to a 312 point size.
>
> BUG=chromium:458791
>
> Committed: https://skia.googlesource.com/skia/+/d2737ad7dd8f4ea94a74034027014fd3d78923cbTBR=joshualitt@google.com,bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:458791
Review URL: https://codereview.chromium.org/986333005
Because of high DPI devices, we need more room in the glyph
atlas for the larger glyphs. These settings will allow 4 of
the distance field glyphs to fit in one Plot (increasing
the storage from 32 large glyphs to 128), and still permit
us to handle glyphs up to a 312 point size.
BUG=chromium:458791
Review URL: https://codereview.chromium.org/986343002
Reason for revert:
Lots of PDF failures -- need to investigate
Original issue's description:
> use colorfilter instead of imagefilter when possible
>
> big speed win w/ nanobench --match colorfilter_
>
> BUG=skia:
> TBR=
>
> Will require rebaselining, so landing temporarily to trigger layouttests.
>
> Committed: https://skia.googlesource.com/skia/+/f641bd076d29666a5d2a10d5384e4924b0a0e524TBR=sugoi@google.com,senorblanco@google.com,bsalomon@google.com,reed@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/991693002
Clarify asColorFilter ...
1. Rename to isColorFilterNode for DAG reduction
2. Add asAColorFilter for removing the imagefilter entirely (future use-case)
Need layouttest rebaseline suppression before this can land in chrome...
https://codereview.chromium.org/984023004/
BUG=skia:
Review URL: https://codereview.chromium.org/982933002
Reason for revert:
Reverting in case this is the cause of the non-Windows failures.
Original issue's description:
> For consistency, use our homebrew zlib everywhere possible.
>
> This switches when we build our own zlib from "just Windows" to "everyone, but
> not Android framework of course".
>
> I tested this by building DM for my Mac and for an Android bot config.
> It took minor tweaks to the GYP to get ARM builds working.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/5a8f2257b0b0f954fb74f65e7ea3ada772ed9240TBR=scroggo@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/989873002
When computed, the RTree for an SkPicture will have a root
bounds that reflects the best bounding information available,
rather than the best estimate at the time the picture recorder
is created. Given that creators frequently don't know ahead of
time what will be drawn, the RTree bound is often tighter.
Perf testing on Chrome indicates a small raster performance
advantage. For upcoming painting changes in Chrome the
performance advantage is much larger.
BUG=
Committed: https://skia.googlesource.com/skia/+/2dd3b6647dc726f36fd8774b3d0d2e83b493aeac
Review URL: https://codereview.chromium.org/971803002
This switches when we build our own zlib from "just Windows" to "everyone, but
not Android framework of course".
I tested this by building DM for my Mac and for an Android bot config.
It took minor tweaks to the GYP to get ARM builds working.
BUG=skia:
Review URL: https://codereview.chromium.org/971673005
The tests assert on Sk_ColorGREEN, which is in BRGA non-premul. Read the
pixels in same color format.
Currently the tests pass on all platforms because GREEN is fully opaque
and the component stays in the same place both on BGRA and
RGBA. However, hypothetically somebody could copy-paste the assertion
for further tests but use, say, RED. This creates latent error that is
only visible on some platforms like mac.
Review URL: https://codereview.chromium.org/989463002
Clamping 4 at a time is now about 15% faster than 1 at a time with SSSE3.
Clamping 4 at a time is now about 20% faster with SSE2,
and this applies to non-clamping too (we still just clamp there).
In all cases, 4 at a time is never worse than 1 at a time,
and not clamping is never slower than clamping.
Here's all the bench results, with the numbers for portable code as a fun point
of reference:
SSSE3:
maxrss loops min median mean max stddev samples config bench
10M 2291 4.66ns 4.66ns 4.66ns 4.68ns 0% ▆█▁▁▁▇▁▇▁▃ nonrendering SkPMFloat_get_1x
10M 2040 5.29ns 5.3ns 5.3ns 5.32ns 0% ▃▆▃▃▁▁▆▃▃█ nonrendering SkPMFloat_clamp_1x
10M 7175 4.62ns 4.62ns 4.62ns 4.63ns 0% ▁▄▃████▃▄▇ nonrendering SkPMFloat_get_4x
10M 5801 4.89ns 4.89ns 4.89ns 4.91ns 0% █▂▄▃▁▃▄█▁▁ nonrendering SkPMFloat_clamp_4x
SSE2:
maxrss loops min median mean max stddev samples config bench
10M 1601 6.02ns 6.05ns 6.04ns 6.08ns 0% █▅▄▅▄▂▁▂▂▂ nonrendering SkPMFloat_get_1x
10M 2918 6.05ns 6.06ns 6.05ns 6.06ns 0% ▂▇▁▇▇▁▇█▇▂ nonrendering SkPMFloat_clamp_1x
10M 3569 5.43ns 5.45ns 5.44ns 5.45ns 0% ▄█▂██▇▁▁▇▇ nonrendering SkPMFloat_get_4x
10M 4168 5.43ns 5.43ns 5.43ns 5.44ns 0% █▄▇▁▇▄▁▁▁▁ nonrendering SkPMFloat_clamp_4x
Portable:
maxrss loops min median mean max stddev samples config bench
10M 500 27.8ns 28.1ns 28ns 28.2ns 0% ▃█▆▃▇▃▆▁▇▂ nonrendering SkPMFloat_get_1x
10M 770 40.1ns 40.2ns 40.2ns 40.3ns 0% ▅▁▃▂▆▄█▂▅▂ nonrendering SkPMFloat_clamp_1x
10M 1269 28.4ns 28.8ns 29.1ns 32.7ns 4% ▂▂▂█▂▁▁▂▁▁ nonrendering SkPMFloat_get_4x
10M 1439 40.2ns 40.4ns 40.4ns 40.5ns 0% ▆▆▆█▁▆▅█▅▆ nonrendering SkPMFloat_clamp_4x
SkPMFloat_neon.h is still one big TODO as far as 4-at-a-time APIs go.
BUG=skia:
Review URL: https://codereview.chromium.org/982123002
Reason for revert:
Need to suppress these for rebaselining, so reverting for now.
Regressions: Unexpected image-only failures (5)
css3/filters/effect-brightness-clamping-hw.html [ ImageOnlyFailure ]
css3/filters/effect-combined-hw.html [ ImageOnlyFailure ]
virtual/slimmingpaint/css3/filters/effect-brightness-clamping-hw.html [ ImageOnlyFailure ]
virtual/slimmingpaint/css3/filters/effect-combined-hw.html [ ImageOnlyFailure ]
Original issue's description:
> Use ComposeColorFilter in factory to collapse consecutive filters (when possible).
> Change asColorFilter to reflect its reliance on the new factory behavior.
>
> patch from issue 967143002 at patchset 80001 (http://crrev.com/967143002#ps80001)
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/dac843bf046c2cd79fd955cb177aee241d7a4b0cTBR=senorblanco@chromium.org,robertphillips@google.com,bsalomon@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/978923005
This blacklist entry bans any test with 'pdf' config, any source type, whose
name has '.webp' in it. In practice, that's 'image' or 'subset' source type
decoding some WEBP file.
BUG=skia:3505
Review URL: https://codereview.chromium.org/982163002
