Reason for revert:
Failing tests
Original issue's description:
> Alter gpu veto
>
> This CL unifies the treatment of the dashed and concave paths.
>
> Before:
> TP 28 FP 15 TN 8 FN 3 IND 3
>
> After:
> TP 28 FP 18 TN 7 FN 2 IND 2
>
> One of the TrueNegatives that became a FalsePositive was the motivation use case (the Chromium busy spinner).
>
> Committed: https://skia.googlesource.com/skia/+/87a6a8e18c7d5bbc94f478b44c53dc0e0549f927TBR=egdaniel@google.com,bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/879483003
This CL unifies the treatment of the dashed and concave paths.
Before:
TP 28 FP 15 TN 8 FN 3 IND 3
After:
TP 28 FP 18 TN 7 FN 2 IND 2
One of the TrueNegatives that became a FalsePositive was the motivation use case (the Chromium busy spinner).
Review URL: https://codereview.chromium.org/875913002
Fold alpha to the inner savelayer in savelayer-savelayer-restore
patterns such as this:
SaveLayer (non-opaque)
Save
ClipRect
SaveLayer
Restore
Restore
Restore
Current blink generates these for example for SVG content such as this:
<path style="opacity:0.5 filter:url(#blur_filter)"/>
The outer save layer is due to the opacity and the inner one is due to
blur filter being implemented with picture image filter.
Reduces layers in desk_carsvg.skp testcase from 115 to 78.
BUG=skia:3119
Review URL: https://codereview.chromium.org/835973005
==7023== 5,056 (896 direct, 4,160 indirect) bytes in 8 blocks are definitely lost in loss record 947 of 2,656
==7023== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7023== by 0x82CB99: SkNewImageFromBitmapTexture(SkBitmap const&, int, SkSurface::Budgeted) (SkImage_Gpu.cpp:64)
==7023== by 0x81A1CF: SkSurface_Gpu::onNewImageSnapshot(SkSurface::Budgeted) (SkSurface_Gpu.cpp:50)
==7023== by 0x694F9D: SkSurface::newImageSnapshot(SkSurface::Budgeted) (SkSurface_Base.h:92)
==7023== by 0x55EA7C: test_Surface(skiatest::Reporter*, GrContextFactory*) (SurfaceTest.cpp:485)
==7023== by 0x407CB2: run_test(skiatest::Test*) (DM.cpp:399)
==7023== by 0x408382: run_enclave_and_gpu_tests(SkTArray<Task, false>*) (DM.cpp:411)
==7023== by 0x68B71E: SkTaskGroup::wait() (SkTaskGroup.cpp:67)
==7023== by 0x40934E: dm_main() (DM.cpp:455)
==7023== by 0x409483: main (DM.cpp:477)
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu12-ShuttleA-GTX550Ti-x86_64-Release-Valgrind/builds/276/steps/dm/logs/stdioTBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/872183002
- add -Wsign-compare, which has been catching useful issues for Kimmo;
- add -Winit-self and -Wpointer-arith to Mac builds so everyone's using
the same flags;
- try try removing -Wno-uninitialized. This was only for the old 10.6
compiler that we have warnings set as non-errors now.
BUG=skia:
Review URL: https://codereview.chromium.org/872793002
gcc (Ubuntu/Linaro 4.6.4-1ubuntu1~12.04) 4.6.4
error: comparison between signed and unsigned integer expressions
Review URL: https://codereview.chromium.org/871013002
This way if a bot crashes, we might get some partial results in gold rather
than none. We do the same sort of thing in nanobench for perf.
BUG=skia:3255
Review URL: https://codereview.chromium.org/872443003
I have been hacking at this test trying to understand why the N5 is
still sometimes crashy (it seems, less but not zero now). No luck so far.
But, while I've been reading and hacking at it, I think I've made a
few small improvements, mostly to readability.
BUG=skia:
Review URL: https://codereview.chromium.org/870803002
This is a speculative fix for the crashing N5 bots. It looks like the bots are
always failing in or around FloatingPointTextureTest.
It looks like sometimes they're hitting a SIGBUS, which I suspect is stack
overflow. FloatingPointTextureTest allocates ~320K on the stack, which may
be too much. This CL moves those buffers to the heap. For consistency I did
the same with the half-float tests, though they're only using ~1/8th the stack.
It looks like sometimes the bots are failing to malloc. I don't understand that,
and this CL doesn't address that directly. But it's possible this is still a stack
overflow, just trashing RAM and causing arbitrary mayhem instead of a SIGBUS.
I have no idea why this is a problem only on the N5. I have been unable to
reproduce this locally, neither with a K N5 nor an L N5, but the bots are pretty
reliable.
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/871623002
Not a big deal, but matches the intention of it being a file-scoped function
better. This mirrors a recent google3 change for clients who don't use C++11.
BUG=skia:
Review URL: https://codereview.chromium.org/865243002
