BUG=skia:
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: Idc76999d0f5591a567b3976cb9db829c350e4be2
Reviewed-on: https://skia-review.googlesource.com/8304
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Alpha type is not (and never will be) part of pixel config, so the logic
around that was unnecessary. (Also, we already sanitize color type and
alpha type before making a new device at a higher level).
With that out of the way, we can easily supply a full info at the two
call-sites that were using the other version.
BUG=skia:
Change-Id: Iceccdbdebd1062d3e5023620755aabcc86604d2f
Reviewed-on: https://skia-review.googlesource.com/6920
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit efcc41805b.
Reason for revert: Possible culprit for Chromium failures.
Original change's description:
> Explicitly fail read/writePixels in invalid color space scenarios
>
> It's not well defined what to do when moving from a nullptr color space to
> a tagged destination (drawing, reading, writing, etc...). In these
> scenarios, at least, we can choose to disallow the operation (rather than
> produce an unexpected or inconsistent result).
>
> BUG=skia:
>
> Change-Id: I033b23c6f2bb00664efc8fdab1b3f52053d77695
> Reviewed-on: https://skia-review.googlesource.com/6600
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Matt Sarett <msarett@google.com>
>
TBR=mtklein@google.com,bsalomon@google.com,msarett@google.com,brianosman@google.com,reviews@skia.org
BUG=skia:
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I17791f9285089ede42b7921324e0dc264865be1d
Reviewed-on: https://skia-review.googlesource.com/6628
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
It's not well defined what to do when moving from a nullptr color space to
a tagged destination (drawing, reading, writing, etc...). In these
scenarios, at least, we can choose to disallow the operation (rather than
produce an unexpected or inconsistent result).
BUG=skia:
Change-Id: I033b23c6f2bb00664efc8fdab1b3f52053d77695
Reviewed-on: https://skia-review.googlesource.com/6600
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
This reverts commit 8e7432b7f9.
Reason for revert: <INSERT REASONING HERE>
external/skia/bench/../tools/android/SkAndroidSDKCanvas.h:103:36: error: C++ requires a type specifier for all declarations
void onClipRect(const SkRect&, ClipOp, ClipEdgeStyle) override;
Original change's description:
> remove SK_SUPPORT_LEGACY_CLIP_REGIONOPS
>
>
> switch over to SkClipOps now that SK_SUPPORT_LEGACY_CLIP_REGIONOPS is gone
>
> BUG=skia:
>
> Change-Id: Ifdc8b3746d508348a40cc009a4e529a1cb3c405d
> Reviewed-on: https://skia-review.googlesource.com/5714
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
>
TBR=reed@google.com,reviews@skia.org
BUG=skia:
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: If26ea91d7464615e43c1d3d2f726e337ff56b55c
Reviewed-on: https://skia-review.googlesource.com/5721
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
switch over to SkClipOps now that SK_SUPPORT_LEGACY_CLIP_REGIONOPS is gone
BUG=skia:
Change-Id: Ifdc8b3746d508348a40cc009a4e529a1cb3c405d
Reviewed-on: https://skia-review.googlesource.com/5714
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
- perform version check in CreateProc for XfermodeImageFilter and ArithmeticImageFilter
This reverts commit 3ed485f424.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2992
Change-Id: Ib4a154cdd5f5d1dcac921ef50d53b79a2d6a1be8
Reviewed-on: https://skia-review.googlesource.com/2992
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).
Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.
Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
Review URL: https://codereview.chromium.org/1789663002
Reason for revert:
We're getting sRGB non-8888 configs?
Original issue's description:
> sRGB support in Ganesh. Several pieces:
>
> sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
> us to disable sRGB -> Linear conversion when reading textures. This gives
> us an easy way to support "legacy" L32 mode. We disable decoding based on
> the pixel config of the render target. Textures can override that behavior
> (specifically for format-conversion draws where we want that behavior).
>
> Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
> internally, and the external format is BGR order, so TexImage calls will
> swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
> platforms.
>
> Devices without sRGB support behave like they always have: conversion from
> color type and profile type ignores sRGB and always returns linear pixel
> configs.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
>
> Committed: https://skia.googlesource.com/skia/+/9e3f1bf4e5cd8fc59554f986f36d6b034e99f9ebTBR=reed@google.com,bsalomon@google.com,robertphillips@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1814533003
sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).
Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.
Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
Review URL: https://codereview.chromium.org/1789663002
Use DEF_GPUTEST_FOR_*_CONTEXT macros to obtain the
test GPU context.
Makes changing the context -related classes easier,
since not all tests need to be changed.
BUG=skia:2992
Review URL: https://codereview.chromium.org/1448873002
