Reason for revert:
I cannot upload patches:
~/skia (skskp) $ git clu --bypass-hooks
++ git log -1 --pretty=%B
+ git cl upload -t update
Using 50% similarity for rename/copy detection. Override with --similarity.
Loaded authentication cookies from /Users/mtklein/.codereview_upload_cookies
Running presubmit upload checks ...
** Presubmit ERRORS **
Since the CL is editing public API, you must have an LGTM from one of: ('reed@chromium.org', 'reed@google.com', 'bsalomon@chromium.org', 'bsalomon@google.com', 'djsollen@chromium.org', 'djsollen@google.com')
Original issue's description:
> Ignore public API checks if COMMIT=false is in the description
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/d1783aefcc0da86c5ff1d124c54704252d817621TBR=borenet@google.com,rmistry@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1005583002
Seems strictly more useful.
This implements Mac and Windows, which seemed easy. Don't know how to do this on Linux yet.
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.9-MacMini6.2-HD4000-x86_64-Debug-Trybot
NOTREECHECKS=true
TBR=halcanary@google.com
Review URL: https://codereview.chromium.org/990723002
Unprotected reads -> relaxed reads.
Unprotected write -> relaxed write.
The only unprotected write we had was in SkTraceEvent, which it looks like we nabbed from Chrome at some point and changed only to silence TSAN. Chrome's version uses AtomicWord / NoBarrier_Load / NoBarrier_Store, which boils down to the same as here, intptr_t / relaxed load / relaxed store.
This leaves one place where we're lying a bit to TSAN, in include/core/SkLazyPtr.h where we're doing a data-dependent consume load. We're telling TSAN it's consume, but telling any other compiler to compile it as relaxed, given how they all upgrade consume to acquire. This eliminates a barrier for us on ARM. How do you guys deal with this? Just use a consume memory order, take the hit, and hope compilers get smarter one day?
BUG=chromium:465721
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/996763002
A glyph position when mapped from canvas space to device space may land
outside the bounds of the current 16 bit integer part of device space.
Device space is already limited to 32 bits for the integer part,
but for a short space in drawText and drawPosText it is currently
limited to 16 bits (SkFixed). Raise this limit by moving to 48.16.
This matches the current similar fix for measureText.
BUG=chromium:375322
Review URL: https://codereview.chromium.org/977623002
SK_BUILD_FOR_WIN is no longer a valid way to check for building on
Windows (go figure). Build everywhere.
Remove the REPORTER_ASSERT, which was the failing part. It also isn't
necessary for the test, which is just that we are not leaking an
SkColorTable.
Also fix indentation.
TBR=bungeman@google.com,mtklein@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3457
Review URL: https://codereview.chromium.org/1002583002
deprecated, use a proxy SkCanvas for the same end: in every draw
call, inspect the paint, changing it to fit within the capabilities
of the Android Java (HWUI) drawing API.
Verified that this allows us to reenable all our ColorFilter tests.
R=djsollen@google.com
Review URL: https://codereview.chromium.org/997183003
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
