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
Retry config support was added to the CQ in https://chromereviews.googleplex.com/240527013/
This CL uses the retry config in Skia's cq.cfg file.
CQ's default failure_retry_weight is 1. We set it to 2 which will immediately go beyond the try job quota and will not retry for failures. It will retry for transient errors.
BUG=chromium:522460
TBR=mtklein
NOTRY=true
Review URL: https://codereview.chromium.org/1330473002
*** Add CodecMode and ScaledCodecMode (in place of
NormalMode), so now we test SkCodec's getPixels() and
SkScaledCodec's getPixels()
*** Don't attempt to test scanline and codec modes using
the dimensions that were recommended for SkScaledCodec.
*** Change tags so that each scale gets its own output
folder.
TODO: Make ScanlineMode and ScanlineSubsetMode support
kOutOfOrder etc. I think this belongs with the gif CL -
I don't want to add test modes that we don't run yet.
BUG=skia:4202
BUG=skia:4238
Review URL: https://codereview.chromium.org/1327433003
We think it'll simplify things to just always get the full metrics.
On most platforms, it's no different, and we think the platforms that
do differ (FreeType) will be nearly just as cheap.
Removing this distinction helps us make SkGlyphCaches concurrent by
removing a state (we-have-only-advances) from its logical state machine.
We see no significant changes running SKPs before and after this CL.
That makes sense, of course, because the SKPs bake some of this into drawPosText.
BUG=skia:
Review URL: https://codereview.chromium.org/1321243004
As you'll see from the BUG line, we have a strong indication that the new Sk4px
methods regress some devices. This restores the old code back as literally as possible
while still fitting in SkOpts framework.
This is ideally temporary breathing room.
We should get an early indication of if those bugs will improve by watching https://perf.skia.org/#4004
BUG=skia:4117,525844,519596,524149
Review URL: https://codereview.chromium.org/1312763009
