| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For now, we still only have the SkColor factory, but the Descriptor can
now carry either an SkColor or SkColor4f specified gradient. Base class
constructor automatically populates both forms of color, so that legacy
raster backend will continue to work, and new backend work can operate
directly from the float4 version.
On the GPU side, we have similar logic, but GrGradientEffect only
keeps one version of colors around: SkColor if the destination is
legacy, and SkColor4f (with an optional gamut xform) if the destination
is gamma correct. The 4f colors are already linear, and we gamut xform
them in setData, so gradients are now fully color-correct in sRGB and
F16 modes...
... unless there are more than three stops. Then we use a texture, and
that code path isn't handled yet. We have a few choices here (do we
use an 8-bit sRGB atlas, or just always use F16 linear atlas so we can
share it among both sRGB and wide-gamut rendering). In any case, I'd
like to defer that to a second CL.
This change does fix the non-texture gradients in the gamut GM.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2337313002
Review-Url: https://codereview.chromium.org/2337313002
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Conversion from sRGB to destination gamut is going to be very common,
so I'm caching that xform (if there is one) on the draw context.
Results verified in the gamut GM (two more boxes correct).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2330553003
Review-Url: https://codereview.chromium.org/2330553003
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Remove special premul handling from gamut xform code
Alpha is a constant, so the gamut transformation results remain unchanged
(it distributes across the linear matrix multiply).
2. Use SkMatrix44 rather than array of floats
Preserves semantic intention, and makes upcoming code (where we transform
colors on the CPU by that matrix) simpler.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2329553002
Review-Url: https://codereview.chromium.org/2329553002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
New helper functions inject the necessary shader
function. Texture lookup functions can now insert
the gamut xform at the appropriate place, too.
As written, could be used to transform non-texture
colors (e.g. vertex colors) as well.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2180803005
Review-Url: https://codereview.chromium.org/2180803005
|
| |
|
|
|
|
|
|
|
|
| |
Public API is really just internal.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2185533005
TBR=bsalomon@google.com
Review-Url: https://codereview.chromium.org/2185533005
|
|
|
GrTextureAccess optionally includes an instance, computed from the src
and dst color spaces. In all common cases (no color space for either src
or dst, or same color space for both), no object is allocated.
This change is orthogonal to my attempts to get color space attached to
render targets - regardless of how we choose to do that, this will give
us the source color space at all points where we are connecting src to
dst.
There are many dangling injection points where I've been inserting
nullptr, but I have a record of all of them. Additionally, there are now
three places (the most common simple paths for bitmap/image rendering)
where things are plumbed enough that I expect to have access to the dst
color space (all marked with XFORMTODO).
In addition to getting the dst color space, I need to inject shader code
and uniform uploading for appendTextureLookup and friends.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2154753003
Review-Url: https://codereview.chromium.org/2154753003
|
brianosman