First baby step on road to replacing SkLazyFnPtr, SkLazyPtr, and SkOnce.
One of those very unusual times you get to use a function type,
not a function pointer type!
BUG=skia:
Review URL: https://codereview.chromium.org/1317263007
The newly created VisualLightweightBenchModule is just the old VisualBench.cpp, but gutted to only include timing code.
Future CLs will harden this abstraction, but for this CL the module owns a backpointer to VisualBench.cpp for a couple of calls.
BUG=skia:
Review URL: https://codereview.chromium.org/1304083007
Image encoding may fail during serialization, resulting in zero-length
encoded data in the SKP.
Instead of invalidating the stream (and preventing deserialization of
the whole picture) we can instantiate placeholder images.
BUG=skia:4285
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1308273011
The SkOneShotDiscardablePixelRef was not overriding
diagnostic_only_getDiscardable method of SkPixelRef. This caused the
memory to be acocunted under malloc instead of discardable and caused
wrong accounting.
BUG=528295
Review URL: https://codereview.chromium.org/1304083006
Add a current version of the patch described in issue 562.
Of interest: the reference row, which is described in the
bug as looking correct draws differently with Ganesh.
TBR=senorblanco
BUG=skia:562
Review URL: https://codereview.chromium.org/1324023006
This should still wait for the device to be attached and finished
booting, but will prevent no-output timeouts due to
`adb wait-for-device` never finishing.
The effect should be that, when an Android device is disconnected, the
"wait for device" step will run forever, or until the device
reconnects. This should prevent a disconnected device from spreading
purple all over the status page.
BUG=skia:
Review URL: https://codereview.chromium.org/1315753010
Some icos have been looking a bit strange in Gold.
Looks like the cause was that we were decoding to kUnpremul
accidentally.
BUG=skia:
Review URL: https://codereview.chromium.org/1321913003
These extra outputs were caused by recent changes to
push_codec_srcs.
https://codereview.chromium.org/1327433003/
*** First, I would argue that we do not want to test
"native" modes (ex: codec, scanline, etc) to scales
that require sampling (ex: 0.1, 0.2, etc). Right now,
we are trying to scale jpegs to 0.1, settling for 0.125
as the closest option, and then trying to compare the
0.125 scaled image to the actual 0.1 scaled image in
Gold.
*** Second, I messed up and caused our test setup to
try to decode to kIndex8 and kGray8 "always" instead
of only when it is recommended. The bad effect of this
happens because we can decode jpegs to kGray8 even if
they are color images. Right now in Gold, we have a
bunch of untriaged gray versions of color images.
The second issue would have been caught if we signaled
a fatal failure for invalid conversions. Maybe we should
look into this now that 565 is supported everywhere?
BUG=skia:
Review URL: https://codereview.chromium.org/1314163007
Reason for revert:
Patch is incorrect -- floating point errors can cause zero-area monotone polys to be skipped, resulting in a smaller vertex count than estimated.
Reproduce as follows:
out/Debug/SampleApp --slide Fuzzer --msaa 4
switch to GPU mode. Result:
../../src/gpu/batches/GrTessellatingPathRenderer.cpp:1500: failed assertion "static_cast<int>(end - verts) == vertexCount"
Original issue's description:
> Minor cleanup in GrTessellatingPathRenderer.
>
> Vertex counts are always exact, so don't bother handling the case
> where they're different. Just assert.
> Rename variables to reflect.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9389b871c3b0f06bb34626cf9bdbfe0c93779327TBR=bsalomon@google.com,senorblanco@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1321723006
