Gradients (and other shaders) are going to end up serializing this
particular color space very frequently, so we want a shorthand way of
writing it out. I think it's also helpful to have a clearer way of
creating it (vs. NewNamed(kSRGB_Named)->makeLinearGamma()).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2377763002
Review-Url: https://codereview.chromium.org/2377763002
Verify the rules that we're converging on for surfaces:
- For 8888, we only support sRGB-like gamma, or no color space at all.
- For F16, we require a color space, with linear gamma.
- For all other formats, we do not support color spaces.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2270823002
Review-Url: https://codereview.chromium.org/2270823002
Keep isOpaque as a convenience method -- many places really only need to
know that for optimization purposes (SrcOver -> Src, etc...).
In all the places where we pull data back out or convert to another
object and need to supply an SkImageInfo, we can avoid losing information
about premulness.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2250663002
Review-Url: https://codereview.chromium.org/2250663002
Reason for revert:
Breaking the ANGLE bots. Message is:
Caught exception 3221225477 EXCEPTION_ACCESS_VIOLATION
8.59m elapsed, 1 active, 82 queued, 315MB RAM, 1442MB peak
unit test SurfaceAttachStencil_Gpu
step returned non-zero exit code: -1073741819
Original issue's description:
> Allow stencils to be attached to render targets created via SkSurface::MakeFromBackendTextureAsRenderTarget
>
> This is a regression from "Refactor to separate backend object lifecycle
> and GpuResource budget decision".
>
> GrGLRenderer::canAttemptStencilAttachment was incorrectly returning false
> for all wrapped render targets. This function should return false only if
> the FBO is wrapped (unowned). If the FBO is owned by Skia, we can attach
> stencils.
>
> BUG=608238
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1924183003
>
> Committed: https://skia.googlesource.com/skia/+/0736f3386820f19c0fe90b5dda2094e253780071TBR=bsalomon@google.com,kkinnunen@nvidia.com,ericrk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=608238
Review-Url: https://codereview.chromium.org/1947143002
Reason for revert:
Breaking the DEPS roll.
Also seems to be causing failure in DM on some Windows bots:
c:\0\build\slave\workdir\build\skia\tests\surfacetest.cpp:963 kShapeColor == bitmap.getColor(kW / 2, kH / 2)
Original issue's description:
> Make stencils be attachable to render targets created via SkSurface::MakeFromBackendTextureAsRenderTarget
>
> This is a regression from "Refactor to separate backend object lifecycle
> and GpuResource budget decision".
>
> GrGLRenderTarget::CreateWrapped creates only render targets that wrap
> the FBO.
> GrGLRenderTargetTexture::CreateWrapped creates render targets that
> wrap the texture.
>
> Use the latter as the implementation for
> SkSurface::MakeFromBackendTextureAsRenderTarget.
>
> The test contains disabled code. The
> MakeFromBackendTextureAsRenderTarget does not copy the existing texture
> contents to the FBO render buffer.
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1924183003
>
> Committed: https://skia.googlesource.com/skia/+/fe635fd76bbc375d527d1884af23cc617ca364eeTBR=bsalomon@google.com,kkinnunen@nvidia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/1931293003
This is a regression from "Refactor to separate backend object lifecycle
and GpuResource budget decision".
GrGLRenderTarget::CreateWrapped creates only render targets that wrap
the FBO.
GrGLRenderTargetTexture::CreateWrapped creates render targets that
wrap the texture.
Use the latter as the implementation for
SkSurface::MakeFromBackendTextureAsRenderTarget.
The test contains disabled code. The
MakeFromBackendTextureAsRenderTarget does not copy the existing texture
contents to the FBO render buffer.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1924183003
Review-Url: https://codereview.chromium.org/1924183003
Add support for feeding the tests with contexts directly to the unit
test framework.
This fixes the problem where tests are more complex than needed just in
order to run the test code with multiple backends.
Also makes it possible to change the logic how contexts are
created. Instead of direct numbering, the different testable contexts
may be generated from filtered cross-product of context options. For
example: currently NVPR is a type of context. However, it could be also
an on/off feature of any context. In order to test this kind of context,
the enumeration can not be just of context type. It's simpler
to move the enumeration out of the tests.
A test targeting both normal and GPU backends would look like:
static void test_obj_behavior(skiatest::Reporter* reporter,
SkObj* obj, [other params] ) {
... test with obj and param ..
}
DEF_TEST(ObjBehavior, reporter) {
for (auto& object : generate_object) {
for (auto& other_param : generate_other_variant) {
test_obj_behavior(reporter, object, other_param);
}
}
}
#if SK_SUPPORT_GPU
DEF_GPUTEST_FOR_ALL_CONTEXTS(ObjBehavior_Gpu, reporter, context) {
for (auto& object : generate_gpu_object) {
for (auto& other_param : generate_other_variant) {
test_obj_behavior(reporter, object, other_param);
}
}
}
#endif
Uses the feature in SurfaceTests as an example.
Moves SkSurface -related tests from ImageTest to SurfaceTest.
BUG=skia:2992
Review URL: https://codereview.chromium.org/1446453003
The general SkImage features seem to be tested in
ImageTest instead of SurfaceTest.
Helps in reviewing further reformatting of SurfaceTest.
BUG=skia:2992
Review URL: https://codereview.chromium.org/1452123002
Prepare_rt_for_external_access() grabs the render target and then fires
access notifications.
But the notification handlers may trigger copy-on-write, causing the
returned render target to be stale (pointing at the detached snapshot).
We should grab the render target after firing notifications.
R=reed@google.com,bsalomon@google.com
Review URL: https://codereview.chromium.org/1276713002
