| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
SampleApp doesn't have (can't easily get) an image, so I couldn't use
the new helper function there. It's probably still worth having?
BUG=skia:
Change-Id: I60c208ff958076015a9539359921b9aff68f25c8
Reviewed-on: https://skia-review.googlesource.com/7129
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
|
|
|
|
|
|
|
|
|
| |
Replace with std::unique_ptr.
Change-Id: I5806cfbb30515fcb20e5e66ce13fb5f3b8728176
Reviewed-on: https://skia-review.googlesource.com/4381
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4020
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Change-Id: I19cd056f2af778f10e8c6c2b7b2735593b43dbac
Reviewed-on: https://skia-review.googlesource.com/4020
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Matches our naming convention for all other types - factories that
return sk_sp (or any type that intelligently manages its own
lifetime) are named Make.
Previous factories are still around, assuming
SK_SUPPORT_LEGACY_COLOR_SPACE_FACTORIES is defined. Enable that
define for Android, etc.
See also: https://codereview.chromium.org/2442053002/
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3822
Change-Id: Iaea9376490736b494e8ffc820831f052bbe1478d
Reviewed-on: https://skia-review.googlesource.com/3822
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The refactoring breaks off A2B0 tag support into a separate
subclass of SkColorSpace_Base, while keeping the current
(besides CLUT) functionality in a XYZTRC subclass.
ICC profile loading is now aware of this and creates the A2B0
subclass when SkColorSpace::NewICC() is called on a profile
in need of the A2B0 functionality.
The LabPCSDemo GM loads a .icc profile containing a LAB PCS and
then runs a Lab->XYZ conversion on an image using it so we can
display it and test out the A2B0 SkColorSpace functionality,
sans a/b/m-curves, as well as the Lab->XYZ conversion code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2389983002
Review-Url: https://codereview.chromium.org/2389983002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It will now reside in SkColorSpace_Base. Future work for SkColorSpace
will cause this function to not be desirable or sensible to call on
all SkColorSpaces. Call sites were changed to make a kSRGBLinear_Named
instead of kSRGB_Named -> makeLinearGamma() (the majority of cases),
and if that was not possible, SkColorSpace_Base::makeLinearGamma()
was called instead.
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2412613005
Review-Url: https://codereview.chromium.org/2412613005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
blacklist. (patchset #2 id:20001 of https://codereview.chromium.org/2383513002/ )
Reason for revert:
Valgrind errors:
==2603== Invalid read of size 8
==2603== at 0xA284E0: SkSurface::getCanvas() (SkSurface_Base.h:108)
==2603== by 0x4F0B0F: gamut_GM(SkCanvas*) (gamut.cpp:163)
==2603== by 0x483B77: DM::GMSrc::draw(SkCanvas*) const (DMSrcSink.cpp:69)
==2603== by 0x485F04: DM::GPUSink::draw(DM::Src const&, SkBitmap*, SkWStream*, SkString*) const (DMSrcSink.cpp:1226)
==2603== by 0x47E974: dm_main() (DM.cpp:1035)
==2603== by 0x6652EC4: (below main) (libc-start.c:287)
==2603== Address 0x20 is not stack'd, malloc'd or (recently) free'd
==2603==
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-ShuttleA-GPU-GTX550Ti-x86_64-Release-Valgrind/builds/1410/steps/test_skia%20on%20Ubuntu/logs/stdio
Original issue's description:
> Fix gamut GM to work w/serialization configs. Remove it from blacklist.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2383513002
>
> Committed: https://skia.googlesource.com/skia/+/e4a17372a188f1dffc3f9c9bcdfbb9860728630b
TBR=reed@google.com,borenet@google.com,brianosman@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/2380313002
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2383513002
Review-Url: https://codereview.chromium.org/2383513002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Texture is F16 linear, unless that's not supported. In that
case, we pack down to sRGB.
Added more test patches to the gamut GM with many stops,
to test this case. Now they render correctly.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2343253002
Review-Url: https://codereview.chromium.org/2343253002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were effectively storing the transpose, which made all of our
operations on individual colors, and our concatenation of matrices
awkward and backwards.
I'm planning to push this further into Ganesh, where I had incorrectly
adjusted to the previous layout, treating colors as row vectors in the
shaders.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2324843003
Review-Url: https://codereview.chromium.org/2324843003
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2319293002
Review-Url: https://codereview.chromium.org/2319293002
|
|
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
|