We occasionally make copies of GrPaints. clone() fill facilitate this case when GrFragmentProcessors are non-shareable..
Change-Id: I004e34f6ce8c293f9e0664d26532e44bd6b9fdff
Reviewed-on: https://skia-review.googlesource.com/26360
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I562d438bd65e9fd900cfc6831f971b4af25c8ae6
Reviewed-on: https://skia-review.googlesource.com/26361
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is part of setting the stage for moving GrFragmentProcessor to unique_ptr ownership.
Change-Id: I2dfb4977319605d56c4debe05ff0b3dc970bb4c5
Reviewed-on: https://skia-review.googlesource.com/26141
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit cd1416efbc.
Reason for revert: speculative, to try to fix roll see gpu_tests.pixel_integration_test.PixelIntegrationTest.Pixel_GpuRasterization_ConcavePaths
Original change's description:
> Add support for semaphores to be inserted on GrContext flush
>
> This also moves the logic of inserting semaphores down into GrDrawingManager
> and finishFlush on GrGpu. With it being on finishFlush, there should be no
> issues when the DrawingManager starts respecting the proxy passed in assuming
> it always calls finishFlush at the end (which it should).
>
> Bug: skia:
> Change-Id: I925c2a289dcbbb9159b9120878af1d34f21a2dc7
> Reviewed-on: https://skia-review.googlesource.com/25641
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Greg Daniel <egdaniel@google.com>
TBR=egdaniel@google.com,bsalomon@google.com,robertphillips@google.com
Change-Id: I9c5b9cf8c060193e1861dbb8f0c10fb11dfb5249
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/25980
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This also moves the logic of inserting semaphores down into GrDrawingManager
and finishFlush on GrGpu. With it being on finishFlush, there should be no
issues when the DrawingManager starts respecting the proxy passed in assuming
it always calls finishFlush at the end (which it should).
Bug: skia:
Change-Id: I925c2a289dcbbb9159b9120878af1d34f21a2dc7
Reviewed-on: https://skia-review.googlesource.com/25641
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This reverts commit 467022b186.
Reason for revert: GrAHardwareBufferImageGenerator.cpp
Original change's description:
> Reduce dependence on GrSurface's origin field
>
> Unfortunately, GrGPU and its ilk are still using the GrSurface's origin a lot. I will clean that up in a second CL.
>
> Change-Id: Iba729440ce8ea8d24bb7f4e5de55ed576a0f176d
> Reviewed-on: https://skia-review.googlesource.com/24700
> Commit-Queue: Robert Phillips <robertphillips@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,robertphillips@google.com
Change-Id: I1b3f5c3b82d250ac164beb1d5c83abb6c3c6ab3b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/25620
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Unfortunately, GrGPU and its ilk are still using the GrSurface's origin a lot. I will clean that up in a second CL.
Change-Id: Iba729440ce8ea8d24bb7f4e5de55ed576a0f176d
Reviewed-on: https://skia-review.googlesource.com/24700
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
[√] convert all stages to use SkJumper_MemoryCtx / be 2d-compatible
[√] convert compile to 2d also, remove 1d run/compile
[√] convert all call sites
[√] no diffs
Change-Id: I3b806eb8fe0c3ec043359616409f7cd1211a1e43
Reviewed-on: https://skia-review.googlesource.com/24263
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
This is mostly dead code.
In order to make it truly dead, we need to opt drawing unpremul images
into SkRasterPipelineBlitter. They had been handled by
SkLinearBitmapPipeline, but can't be draw by SkBitmapProcLegacyShader.
Drawing unpremul images is tested by the GM all_variants_8888, which
gave us trouble last time around (serialize-8888 drew right, 8888 wrong)
but now draws fine. I think this was probably also the root of the
revert, drawing some unpremul image in Chrome's tests somewhere.
Change-Id: I453f9df44ade807316935921cbae82961e2f08aa
Reviewed-on: https://skia-review.googlesource.com/24862
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Instead of query and maxSampleCount and using that to cap, we now have
each config store its supported values and when requested returns either
the next highest or equal supported value, or if non the max config supported.
Bug: skia:
Change-Id: I8802d44c13b3b1703ee54a7e69b82102d4b8dc2d
Reviewed-on: https://skia-review.googlesource.com/24302
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Previously, we reported the first image as soon as it was available. As
a result, in crrev.com/2565323003, InitializeNewFrame might be called
before the metadata is known, meaning it would read the wrong metadata.
Instead of looking at the imagesCount(), SkGifCodec::NewFromStream looks
at frameContext(0), which may still exist even if it's not yet counted
in imagesCount().
Add a test that confirms the desired behavior.
Change-Id: Ib392721ecd2218ba0fcd35aaa64117c0ba3e4ea6
Reviewed-on: https://skia-review.googlesource.com/24405
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
gather_i8 is now unused, so we can remove it.
That in turn makes the ctable field of SkJumper_GatherCtx unused.
After removing ctable, SkJumper_GatherCtx and SkJumper_PtrStride look
identical, so I've now fused them into SkJumper_MemoryCtx, which will
eventually be used by everything loading from, gathering from, or
storing to memory.
Change-Id: Ia882d2dbd54c9fcf9a8250a1ce83304389dd284a
Reviewed-on: https://skia-review.googlesource.com/24085
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
- Add run_2d(x,y,w,h) and start_pipeline_2d().
- Add and test a 2d-compatible store_8888_2d stage.
Change-Id: Ib9c225d1b8cb40471ae4333df1d06eec4d506f8a
Reviewed-on: https://skia-review.googlesource.com/24401
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Needs google3 to be updated before this can land.
Bug: skia:6828
Change-Id: I2c16be13c6937ffa48768cc24f9f980171c824d6
Reviewed-on: https://skia-review.googlesource.com/23940
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: I395e3387df44cf5370fef6ab73db73228225622f
Reviewed-on: https://skia-review.googlesource.com/23946
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Update NewFromStream to report an error on failure to create an
SkCodec, so that a client can distinguish between
- not enough data
- invalid data
In Chromium, this will allow blink::ImageDecoder to call SetFailed if
the stream is invalid early and we never create an SkCodec. Without
this, ImageDecoder will keep trying to create an SkCodec when it
receives more data.
Change-Id: I4f505c56d91c982be36a828fd0f7db17b1596588
Reviewed-on: https://skia-review.googlesource.com/22642
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Chris Blume <cblume@chromium.org>
Fixes the threshold logic for "0 ~= d1 && 0 ~= d2".
Previously, if d1 and d2 were both near zero, but on opposite sides
of the threshold, the curve could be misclassified as kCuspAtInfinity
and drawn incorrectly.
Bug: skia:
Change-Id: I65f30ddebf0a4a0b933610d8cc1a2f489efc99e4
Reviewed-on: https://skia-review.googlesource.com/22400
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Previously, if ReadHeader returned false, it deleted the input stream.
But there are a couple of cases where ReadHeader creates an SkCodec and
then returns false. The SkCodec deletes the stream, and then so does
NewFromStream.
Make sure that we do not double delete by only deleting if no SkCodec
was created.
Add a test, so such a double delete will be caught by the bots.
Bug: b/37623797
Change-Id: I787422c9af58f0b92ad9e9ef9ad87c54a12f5e31
Reviewed-on: https://skia-review.googlesource.com/23620
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
We're currently adding picture shader cache entries to the resource
cache, but we don't ever purge. To avoid exhausting the budget, add
logic to associate cached entries with their owning picture shader, and
purge when the shader is deleted.
-- Side note --
The current cache key is
K(pictureID, ...)
so technically the cache entries are associated with the picture, not the
shader. One could resonably argue we should only purge when the
*picture* is deleted. Unfortunately, this doesn't work: the cache entries
contain indirect refs to the picture (SkImageShader -> SkImage_Generated
-> SkPictureImageGenerator -> SkPicture), so the picture is always kept
alive.
Associating the cache entries with the shader itself seems like a
reasonable alternative, even if we give up some cache persistence in the
process.
Change-Id: Ia115dbb5ae627e5ee171da7c4430fecfd42f4292
Reviewed-on: https://skia-review.googlesource.com/23380
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Bug: skia:
Change-Id: I84dbd56c17d4856496af4491f340ec560e29c8a6
Reviewed-on: https://skia-review.googlesource.com/23200
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
