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
SkMatrix::scale and ::rotate take a point around which to scale or rotate.
Canvas lacks these helpers, so the code to rotate a canvas around a
point has been duplicated many times. Factor all of these
implementations into SkCanvas::rotate.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2142033002
Review-Url: https://codereview.chromium.org/2142033002
With the GPU backend, allow F16 render targets to be created (along with
any other renderable format). We were previously just falling back to 8888.
In SampleApp, if the window configuration is F16, don't render directly
to the primary surface (which is actually sRGB 8888). Intead, make an
off-screen F16 surface, then blit it back to the framebuffer when we're done.
In DM, clamp values outside of [0,1]. These were wrapping, producing very
incorrect images. (Many filters can trigger out-of-range values due to
ringing).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890923003
Review URL: https://codereview.chromium.org/1890923003
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
The C++ standard library uses the name "release" for the operation we call "detach".
Rewriting each "detach(" to "release(" brings us a step closer to using standard library types directly (e.g. std::unique_ptr instead of SkAutoTDelete).
This was a fairly blind transformation. There may have been unintentional conversions in here, but it's probably for the best to have everything uniformly say "release".
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1809733002
Review URL: https://codereview.chromium.org/1809733002
The current behavior is to create tiles from the rounded ideal tile size,
tell the tile that it's upper left pixel is at the ideal location, and
then draw those tiles at the ideal locations. As a result, the tiles are
be out of phase with each other internally and then actually drawn at
the rounded pixel location instead of the ideal location.
The new behavior is to always round up to get the tile size, make the
tile translation an integer offset, and then draw at the exact pixel.
This also modifies SampleApp to use the numeric keypad to provide an
extra manual 1/32 pixel translation for fine grained movement.
BUG=skia:5020
Review URL: https://codereview.chromium.org/1763833002
Remove SkWindow::setColorType, it is used wrong and inconsistently.
The color type is actually property of window backbuffer, used when the
window is painted with software. This is as opposed to a generic window
property that would affect all operation.
Similar to MSAA sample count for window GPU backbuffer, the bitmap
backbuffer color type should be a parameter of "attach" or "create
window" functions, should this property ever be added back.
The apps use the call wrong, setting the type as kRGBA_8888
or kBGRRA_8888 without no apparent rationale. These color types
are incorrect, as the raster surface can not work with these.
Reorganize the SkWindow::resize, since no change in SkWindow backbuffer size does not neccessarily mean that SkView would not need the call.
Do not show the sw backbuffer color type in SampleApp title, as
it does not really provide any information. On small screens,
kBGRA_8888_ColorType fills up the whole title.
BUG=skia:4733
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1595503002
Review URL: https://codereview.chromium.org/1595503002
