Reason for revert:
GM breakage. Changes to SkGr.cpp appear to be altering behavior on a variety of tests. Debugging...
Original issue's description:
> Progress on gamma-correctness in the GPU backend. Fixed conversion of color and profile type to pixel config, which makes many things "just work".
>
> Added (color=8888|f16|srgb) option to gpu configurations, along with gpuf16, gpusrgb, and anglesrgb predefined configs. Runs the gpu backend in gamma-correct mode (with either FP16 linear or sRGB 8888 frambuffers).
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1750383002
>
> Committed: https://skia.googlesource.com/skia/+/a6f58194733c1c50e4fe5f98585e42344f29b6f0TBR=mtklein@google.com,bsalomon@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/1755553003
- Use std::atomic directly.
- No more need for SkPODSpinlock or SK_DECLARE_STATIC_SPINLOCK.
Now simple code like this works as you'd hope:
static SkSpinlock gLock;
That is, it starts unlocked and there's no static initializer.
std::atomic_flag would make this terser and standard-guaranteed,
but ATOMIC_FLAG_INIT caused not-yet-implemented errors on MSVC 2013.
The generated code for this approach is identical.
It appears the implicit constructor is constexpr when all the member
initializers are. I'm hoping this way of producing constexpr constructors
without typing "constexpr" gives us a way to eliminate more SkFoo / SkBaseFoo
distinctions and SK_DECLARE_STATIC_FOO. This was certainly the easiest.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1734383002
Review URL: https://codereview.chromium.org/1734383002
Reason for revert:
Breaks Ubuntu and Mac CMAKE
Original issue's description:
> Make SkPicture/SkImageGenerator default to SkCodec
>
> Remove reference to SkImageDecoder from SkPicture. Make the default
> InstallPixelRefProc passed to CreateFromStream use
> SkImageGenerator::NewFromEncoded instead.
>
> Make SkImageGenerator::NewFromEncoded create an SkCodecImageGenerator.
> Remove the old version that used SkImageDecoder.
>
> Remove all versions of lazy_decode_bitmap/LazyDecodeBitmap. The default
> now behaves lazily.
>
> Update all clients to use the default.
>
> Move SkImageDecoderGenerator into KtxTest.cpp, and use it directly.
>
> BUG=skia:4691
> BUG=skia:4290
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1671193002
>
> Committed: https://skia.googlesource.com/skia/+/026388a01864c74208ad57d1ba4f711602d101c6TBR=msarett@google.com,reed@google.com,scroggo@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4691
Review URL: https://codereview.chromium.org/1685963004
Remove reference to SkImageDecoder from SkPicture. Make the default
InstallPixelRefProc passed to CreateFromStream use
SkImageGenerator::NewFromEncoded instead.
Make SkImageGenerator::NewFromEncoded create an SkCodecImageGenerator.
Remove the old version that used SkImageDecoder.
Remove all versions of lazy_decode_bitmap/LazyDecodeBitmap. The default
now behaves lazily.
Update all clients to use the default.
Move SkImageDecoderGenerator into KtxTest.cpp, and use it directly.
BUG=skia:4691
BUG=skia:4290
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1671193002
Review URL: https://codereview.chromium.org/1671193002
RAW images use a lot of memory. Add a new FLAG to run one at a time so
we have less risk of running out of memory.
Isolate RAW images to their own thread on particular devices where our
images cause OOM errors.
Locally, this drops the max memory use from 3945 MB to 1664 MB (running only --image --images <RAW images we test>)
BUG=skia:4912
BUG=skia:4878
BUG=b/27035849
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1681553003
Review URL: https://codereview.chromium.org/1681553003
If a client requests unpremul or premul from an opaque SkCodec,
support it. The opaque image can be treated as any of them, though
it will be less efficient to draw than if the client had used
opaque.
Change the filling code (i.e. for incomplete images) to base its color on
the source alpha type. Prior to adding the support to decode opaque to
any, it was fine to use either source or dest (which would have yielded
the same result). If the client requests non-opaque, we do not want this
to switch the fill value from black to transparent. This also allows
simplifying the signatures for getFillValue and onGetFillValue.
In CodexTest, expect the same result when decoding opaque to *premul,
and compare to the opaque version.
BUG=skia:4616
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1641273003
Review URL: https://codereview.chromium.org/1641273003
Bump SK_IMAGE_VERSION to test the images in v2 in GoogleStorage, which
includes the images from v1 plus test images for SkRawCodec.
Only define skia_decodes_raw on platforms that support it, rather than
defining it always and checking additional conditions to determine
whether to support raw. Further, define it and SK_CODEC_DECODES_RAW
for all targets, so we can use the compile flag in other targets.
In DM, exclude the raw extensions if SK_CODEC_DECODES_RAW is not defined.
Blacklist raw extensions on NexusPlayer, which was running out of memory
when running them.
BUG=skia:4829
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1612113002
Review URL: https://codereview.chromium.org/1612113002
Reason for revert:
Speculative to fix windows bots
Original issue's description:
> Treat bad values passed to --images as a fatal error
>
> If an option is passed to --images that is either a non-existent path or
> a folder with no images matching the supported types, assume this is
> an error and exit, so they can supply a valid path instead.
>
> Share code between DM and nanobench in SkCommonFlags.
>
> nanobench now behaves more like DM - it will check a directory for
> images that match the supported extensions.
>
> Only consider image paths ending in RAW suffixes as images if
> SK_CODE_DECODES_RAW is defined. This prevents us from seeing failure
> to decode errors on platforms that cannot decode it.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1611323004
>
> Committed: https://skia.googlesource.com/skia/+/7579786f3bd5a8fda84a1abc45b16213c3371f93TBR=mtklein@google.com,borenet@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review URL: https://codereview.chromium.org/1653543002
If an option is passed to --images that is either a non-existent path or
a folder with no images matching the supported types, assume this is
an error and exit, so they can supply a valid path instead.
Share code between DM and nanobench in SkCommonFlags.
nanobench now behaves more like DM - it will check a directory for
images that match the supported extensions.
Only consider image paths ending in RAW suffixes as images if
SK_CODE_DECODES_RAW is defined. This prevents us from seeing failure
to decode errors on platforms that cannot decode it.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1611323004
Review URL: https://codereview.chromium.org/1611323004
- add ViaPicture
- run ViaPicture on most bots
- run ViaSecondPicture (tests SkPictureRecorder reuse) and ViaTwice (tests caching) on some bots
- extend ViaSerialization reference checking to ViaPicture, ViaSecondPicture,
ViaSingletonPictures, and ViaTwice
- suppress current reference check failures with --blacklist
I'm open to following up on changing how those suppressions work.
Passing --nocheck turns off these invariant checks, letting us debug failures with normal image diff tools.
CQ_EXTRA_TRYBOTS=client.skia:Test-Win8-MSVC-ShuttleB-CPU-AVX2-x86_64-Release-Trybot
BUG=skia:4769
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1569823006
Review URL: https://codereview.chromium.org/1569823006
Remove refcounting from SkGLContext.
SkGLContext is expected to behave like GrContextFactory would own
it, as implied by the GrContextFactory function.
If it is refcounted, this does not hold.
Also other use sites, such as in SkOSWindow_win (command buffer gl
object), confirm the behavior. The object is explicitly owned and
destroyed, not shared.
Also fixes potential crashes from using GL context of an abandoned
context.
Also fixes potential crashes in DM/nanobench, if the GrContext lives
longer than GLContext through internal refing of GrContext.
Moves the non-trivial implementations from GrContextFactory.h to
.cpp, just for consistency sake.
Changes pathops_unittest.gyp. The pathops_unittest uses
GrContextFactory, but did not link to its implementation. The reason
they worked was that the implementation used (constructors, destructors)
happened to be in the .h file.
This works towards being able to use command buffer and NVPR from
the SampleApp.
BUG=skia:2992
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1511773005
Committed: https://skia.googlesource.com/skia/+/830e012187f951d49d7e46e196ac8d1e653a25da
Review URL: https://codereview.chromium.org/1511773005
Even in GPU configs, encoding a .png and writing to disk is thread safe.
This CL moves that work to an SkTaskGroup, offloading it from the GPU
thread to a threadpool.
In my brief local testing, this makes DM run in about half the time
for GPU-bound work, e.g.
$ out/Release/dm --src gm --config gpudft -w output
Before: 43.79 real 37.01 user 4.28 sys
After : 23.64 real 39.31 user 4.46 sys
This won't affect the bots much, as they already skip .png generation
when gold.skia.org already has a .png of an image with a given hash.
(Most of the time saved here is under WriteToDisk() after the
gUninterestingHashes check.)
CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.9-Clang-MacMini6.2-GPU-HD4000-x86_64-Release-Trybot
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1561553002
Review URL: https://codereview.chromium.org/1561553002
Reason for revert:
Broke tests on Android, iOS, Mac and Windows.
Original issue's description:
> Make SkGLContext lifetime more well-defined
>
> Remove refcounting from SkGLContext.
>
> SkGLContext is expected to behave like GrContextFactory would own
> it, as implied by the GrContextFactory function.
>
> If it is refcounted, this does not hold.
>
> Also other use sites, such as in SkOSWindow_win (command buffer gl
> object), confirm the behavior. The object is explicitly owned and
> destroyed, not shared.
>
> Also fixes potential crashes from using GL context of an abandoned
> context.
>
> Also fixes potential crashes in DM/nanobench, if the GrContext lives
> longer than GLContext through internal refing of GrContext.
>
> Moves the non-trivial implementations from GrContextFactory.h to
> .cpp, just for consistency sake.
>
> Changes pathops_unittest.gyp. The pathops_unittest uses
> GrContextFactory, but did not link to its implementation. The reason
> they worked was that the implementation used (constructors, destructors)
> happened to be in the .h file.
>
> This works towards being able to use command buffer and NVPR from
> the SampleApp.
>
> BUG=skia:2992
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1511773005
>
> Committed: https://skia.googlesource.com/skia/+/830e012187f951d49d7e46e196ac8d1e653a25daTBR=bsalomon@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1555053003
Remove refcounting from SkGLContext.
SkGLContext is expected to behave like GrContextFactory would own
it, as implied by the GrContextFactory function.
If it is refcounted, this does not hold.
Also other use sites, such as in SkOSWindow_win (command buffer gl
object), confirm the behavior. The object is explicitly owned and
destroyed, not shared.
Also fixes potential crashes from using GL context of an abandoned
context.
Also fixes potential crashes in DM/nanobench, if the GrContext lives
longer than GLContext through internal refing of GrContext.
Moves the non-trivial implementations from GrContextFactory.h to
.cpp, just for consistency sake.
Changes pathops_unittest.gyp. The pathops_unittest uses
GrContextFactory, but did not link to its implementation. The reason
they worked was that the implementation used (constructors, destructors)
happened to be in the .h file.
This works towards being able to use command buffer and NVPR from
the SampleApp.
BUG=skia:2992
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1511773005
Review URL: https://codereview.chromium.org/1511773005
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825b
Committed: https://skia.googlesource.com/skia/+/9ebc3f0ee6db215dde461dc4777d85988cf272dd
Review URL: https://codereview.chromium.org/1490113005
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825b
Review URL: https://codereview.chromium.org/1490113005
Reason for revert:
This CL changed 1200 images on gold, when I wouldn't expect any diffs from the description.
Original issue's description:
> Add config options to run different GPU APIs to dm and nanobench
>
> Add extended config specification form that can be used to run different
> gpu backend with different APIs.
>
> The configs can be specified with the form:
> gpu(api=string,dit=bool,nvpr=bool,samples=int)
>
> This replaces and removes the --gpuAPI flag.
>
> All existing configs should still work.
>
> Adds following documentation:
>
> out/Debug/dm --help config
>
> Flags:
> --config: type: string default: 565 8888 gpu nonrendering
> Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
> nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
> xps or use extended form 'backend(option=value,...)'.
>
> Extended form: 'backend(option=value,...)'
>
> Possible backends and options:
>
> gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
> api type: string default: native.
> Select graphics API to use with gpu backend.
> Options:
> native Use platform default OpenGL or OpenGL ES backend.
> gl Use OpenGL.
> gles Use OpenGL ES.
> debug Use debug OpenGL.
> null Use null OpenGL.
> dit type: bool default: false.
> Use device independent text.
> nvpr type: bool default: false.
> Use NV_path_rendering OpenGL and OpenGL ES extension.
> samples type: int default: 0.
> Use multisampling with N samples.
>
> Predefined configs:
>
> gpu = gpu()
> msaa4 = gpu(samples=4)
> msaa16 = gpu(samples=16)
> nvprmsaa4 = gpu(nvpr=true,samples=4)
> nvprmsaa16 = gpu(nvpr=true,samples=16)
> gpudft = gpu(dit=true)
> gpudebug = gpu(api=debug)
> gpunull = gpu(api=null)
> debug = gpu(api=debug)
> nullgpu = gpu(api=null)
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
>
> Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825bTBR=mtklein@google.com,bsalomon@google.com,scroggo@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1536963002
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Review URL: https://codereview.chromium.org/1490113005
Reason for revert:
speculative revert to see if it unblocks the DEPS roll
https://codereview.chromium.org/1529443002
Original issue's description:
> Add config options to run different GPU APIs to dm and nanobench
>
> Add extended config specification form that can be used to run different
> gpu backend with different APIs.
>
> The configs can be specified with the form:
> gpu(api=string,dit=bool,nvpr=bool,samples=int)
>
> This replaces and removes the --gpuAPI flag.
>
> All existing configs should still work.
>
> Adds following documentation:
>
> out/Debug/dm --help config
>
> Flags:
> --config: type: string default: 565 8888 gpu nonrendering
> Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
> nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
> xps or use extended form 'backend(option=value,...)'.
>
> Extended form: 'backend(option=value,...)'
>
> Possible backends and options:
>
> gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
> api type: string default: native.
> Select graphics API to use with gpu backend.
> Options:
> native Use platform default OpenGL or OpenGL ES backend.
> gl Use OpenGL.
> gles Use OpenGL ES.
> debug Use debug OpenGL.
> null Use null OpenGL.
> dit type: bool default: false.
> Use device independent text.
> nvpr type: bool default: false.
> Use NV_path_rendering OpenGL and OpenGL ES extension.
> samples type: int default: 0.
> Use multisampling with N samples.
>
> Predefined configs:
>
> gpu = gpu()
> msaa4 = gpu(samples=4)
> msaa16 = gpu(samples=16)
> nvprmsaa4 = gpu(nvpr=true,samples=4)
> nvprmsaa16 = gpu(nvpr=true,samples=16)
> gpudft = gpu(dit=true)
> gpudebug = gpu(api=debug)
> gpunull = gpu(api=null)
> debug = gpu(api=debug)
> nullgpu = gpu(api=null)
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23TBR=bsalomon@google.com,scroggo@google.com,joshualitt@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1528473002
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Review URL: https://codereview.chromium.org/1490113005
This should fix some odd formatting problems in the logs, e.g.
Note tally:
583x (skipped: Cannot convert to requested color type.
)
4x (--blacklist _ image decode 4bpp-pixeldata-cropped.bmp)
~~~>
Note tally:
583x (skipped: Cannot convert to requested color type.)
4x (--blacklist _ image decode 4bpp-pixeldata-cropped.bmp)
BUG=skia:
Review URL: https://codereview.chromium.org/1508223006
This should make the (veto) and (skipped: ) both less verbose and easier to grok.
Looks like this'll bring the log files down from ~50M to ~1.5M.
BUG=skia:
Review URL: https://codereview.chromium.org/1516563002
Reason for revert:
BUG=skia:4609
skbug.com/4609
Seems like GrContextFactory needs to fail when the NVPR option is requested but the driver version isn't sufficiently high.
Original issue's description:
> Make NVPR a GL context option instead of a GL context
>
> Make NVPR a GL context option instead of a GL context.
> This may enable NVPR to be run with command buffer
> interface.
>
> No functionality change in DM or nanobench. NVPR can
> only be run with normal GL APIs.
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/eeebdb538d476c1bfc8b63a946094ca1b505ecd1TBR=mtklein@google.com,jvanverth@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1486153002
Make NVPR a GL context option instead of a GL context.
This may enable NVPR to be run with command buffer
interface.
No functionality change in DM or nanobench. NVPR can
only be run with normal GL APIs.
BUG=skia:2992
Review URL: https://codereview.chromium.org/1448883002
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
Rename SkCodecTools.h to SkBitmapRegionDecoderPriv.h
Move BRD code to its own directory in tools. This
allows us to not need to expose the entire tools
directory in Android.
BUG=skia:
Review URL: https://codereview.chromium.org/1417393004
We no longer need to worry about namespace
conflicts SkBitmapRegionDecoder in Android (which
we are replacing).
Additionally, the static Create() function does not
need to repeat the name BitmapRegionDecoder.
BUG=skia:
Review URL: https://codereview.chromium.org/1415243007
Remove double negative.
Also, change another error message to be slightly (meaningfully)
different so I can find the right one based on the log.
Review URL: https://codereview.chromium.org/1424083004
In SkSampledCodec, allow the native codec to do its scaling first, then
sample on top of that. Since the only codec which can do native scaling
is JPEG, and we know what it can do, hard-code for JPEG. Check to see
if the sampleSize is something JPEG supports, or a multiple of
something it supports. If so, use JPEG directly or combine them.
BUG=skia:4320
Review URL: https://codereview.chromium.org/1417583009
This involves disabling webps for kCanvas_Strategy.
We have not yet implemented webp subset decodes for this
strategy.
BUG=skia:4521
Review URL: https://codereview.chromium.org/1405273004
The result SkBitmap, the pixel allocator, and the alpha
preference need to be communicated from the client to
the region decoder.
BUG=skia:
Review URL: https://codereview.chromium.org/1418093006
We've migrated SkHwuiRenderer into the Android Framework as
android::uirenderer::TestWindowContext in response to an internal
bug; we now delete that class and change our build references here.
R=djsollen@google.com
Review URL: https://codereview.chromium.org/1407053009
Turns out bitmap.eraseColor() does nothing if the bitmap
is kIndex8. We need a more reliable way to initialize
all of the pixels that we look at in Gold.
The input SkCanvas* is always zero initialized, so let's
only draw pixels to the canvas if we have initialized them.
BUG=skia:
Review URL: https://codereview.chromium.org/1418913002
We will implement this API using SkCodecs.
SkAndroidCodecs will be used to implement the
BitmapRegionDecoder Java API (and possibly
BitmapFactory).
BUG=skia:
Review URL: https://codereview.chromium.org/1406223002
Passing &SkGoodHash to SkTHashMap and SkTHashSet doesn't guarantee that it's actually instantiated. Using a functor does.
BUG=skia:
Review URL: https://codereview.chromium.org/1405053002
This CL allows the SkScanlineDecoder to decode partial
scanlines.
This is a first step in efficiently implementing subsetting
in SkScaledCodec.
BUG=skia:4209
Review URL: https://codereview.chromium.org/1390213002
Use SkCodecPrintf instead of SkDebugf.
Check if the conversion is possible rather than starting many decodes
that will certainly fail.
Small refactor to code that deals with subsets that fall outside
of the image.
BUG=skia:
Review URL: https://codereview.chromium.org/1395383002
Rather than implementing some sort of "fill" in every
SkCodec subclass for incomplete images, let's make the
parent class handle this situation.
This includes an API change to SkCodec.h
SkCodec::getScanlines() now returns the number of lines it
read successfully, rather than an SkCodec::Result enum.
getScanlines() most often fails on an incomplete input, in
which case it is useful to know how many lines were
successfully decoded - this provides more information than
kIncomplete vs kSuccess. We do lose information when the
API is used improperly, as we are no longer able to return
kInvalidParameter or kScanlineNotStarted.
Known Issues:
Does not work for incomplete fFrameIsSubset gifs.
Does not work for incomplete icos.
BUG=skia:
Review URL: https://codereview.chromium.org/1332053002
drawImage calls now properly embeds the original jpeg.
NOTE: drawBitmap*() calls no longer embed JPEG files when
possible (this is in advance of eliminating bitmaps backed
by encoded data). Chromium has already moved from
drawBitmap to drawImage.
Comparisons:
control:
total PDF drawImage/drawBitmap calls: 8010
total PDF jpeg images: 0
total PDF regular images: 3581
experiament:
total PDF drawImage/drawBitmap calls: 8014
total PDF jpeg images: 271
total PDF regular images: 3311
total PDF regular images: 3582 (271 + 3311)
When comparing rendered output there were perceptual
differences in the following four GMs: colorcube, emboss,
colormatrix, and tablecolorfilter. All of these differences
were improvements (that is, closer to the 8888 rendering)
due fixing a bug with colorfilters and forgetting to call
notifyPixelsChanged.
No SKPs had perceptual differences.
Total PDF size dropped from 133964 kB to 126276 kB, a 5.7%
improvement (mostly due to restoring use of JPG images in
SKPs).
BUG=skia:4370
Review URL: https://codereview.chromium.org/1372783003
Looking in Gold, I see some ICO images that only show the upper left
corner of the originals. It is happening because we use different ways
of deciding what the dimensions are:
In CodecSrc::size(), we use an SkScaledCodec to get the dimensions,
even when fMode is not kScaledCodec_Mode.
In CodecSrc::draw(), we only use SkScaledCodec in kScaledCodec_Mode.
My recent CL to combine SkScanlineDecoder with SkCodec revealed this
bug, because now SkScaledCodec::NewFromStream will succeed on ICO.
(Previously, it failed because we do not yet have a scanline decoder
for ICO (skbug.com/4404). Now that they are combined, we would need
to specially flag ICO to stop returning an SkScaledCodec.)
Switch size() to use the correct type of codec.
Review URL: https://codereview.chromium.org/1373253004
Benefits:
- This mimics other decoding APIs (including the ones SkCodec relies
on, e.g. a png_struct, which can be used to decode an entire image or
one line at a time).
- It allows a client to ask us to do what we can do efficiently - i.e.
start from encoded data and either decode the whole thing or scanlines.
- It removes the duplicate methods which appeared in both SkCodec and
SkScanlineDecoder (some of which, e.g. in SkJpegScanlineDecoder, just
call fCodec->sameMethod()).
- It simplifies moving more checks into the base class (e.g. the
examples in skbug.com/4284).
BUG=skia:4175
BUG=skia:4284
=====================================================================
SkScanlineDecoder.h/.cpp:
Removed.
SkCodec.h/.cpp:
Add methods, enums, and variables which were previously in
SkScanlineDecoder.
Default fCurrScanline to -1, as a sentinel that start has not been
called.
General changes:
Convert SkScanlineDecoders to SkCodecs.
General changes in SkCodec subclasses:
Merge SkScanlineDecoder implementation into SkCodec. Most (all?) owned
an SkCodec, so they now call this-> instead of fCodec->.
SkBmpCodec.h/.cpp:
Replace the unused rowOrder method with an override for
onGetScanlineOrder.
Make getDstRow const, since it is called by onGetY, which is const.
SkCodec_libpng.h/.cpp:
Make SkPngCodec an abstract class, with two subclasses which handle
scanline decoding separately (they share code for decoding the entire
image). Reimplement onReallyHasAlpha so that it can return the most
recent result (e.g. after a scanline decode which only decoded part
of the image) or a better answer (e.g. if the whole image is known to
be opaque).
Compute fNumberPasses early, so we know which subclass to instantiate.
Make SkPngInterlaceScanlineDecoder use the base class' fCurrScanline
rather than a separate variable.
CodexTest.cpp:
Add tests for the state changes in SkCodec (need to call start before
decoding scanlines; calling getPixels means that start will need to
be called again before decoding more scanlines).
Add a test which decodes in stripes, currently only used for an
interlaced PNG.
TODO: Add tests for onReallyHasAlpha.
Review URL: https://codereview.chromium.org/1365313002
- use C++11 features ({} init, move constructors) to eliminate the need
for explicit constructors
- collapse RECORD0...RECORD8 into just one RECORD macro
- explicitly tag record types instead of using member detectors.
Removing member detectors makes this code significantly less fragile.
This exposes a few places where we didn't really think through what to do
with SkDrawable. I've marked them TODO for now.
BUG=skia:
Review URL: https://codereview.chromium.org/1360943003
Motivation: I want too finalize this API before working on the more
complex problem of adding XMP metadata for PDF/A.
BUG=skia:3110
Review URL: https://codereview.chromium.org/1359943003
SkBitmapRegionDecoderInterface provides an interface
for multiple implementations of Android's
BitmapRegionDecoder.
We already have correctness tests in DM that will enable us
to compare the quality of our various BRD implementations.
We also need these performance tests to compare the speed
of our various implementations.
BUG=skia:4357
Review URL: https://codereview.chromium.org/1344993003
Right now we have a bug in Gold where some images are labeled
_0.167 and others are labeled _0.166. They are all 1/6
scales and should be labeled the same way and compared.
The fix involves changing 0.166 to 0.167 in the list of
scales that we test on, but SkScaledCodec does not scale
to 0.167 as I expected.
SkScaledCodec converts 0.167 to sampleSize = 5.999 and then
casts to sampleSize = 5. I would argue that we should do
a true round, so 0.167 represents a sampleSize of 6.
In general, this CL change onGetScaledDimensions so that
we now round desiredScale to the nearest sampleSize.
BUG=skia:
Review URL: https://codereview.chromium.org/1356923002
BitmapRegionSampler (uses SkImageDecoder) will often scale
to a power of 2 regardless of the sampleSize requested.
This is skbug.com/4319.
Consider a 60x60 image.
To decode a subset with sample size 3, we might ask for the
following.
[x, y, w, h] = [-15, -15, 30, 30]
sampleSize = 3
Since w = 30 and h = 30, this should give us a 10x10
result. Only the bottom right 5x5 quadrant of this 10x10
subset will actually be in the image. We should get a 5
pixel border on the top and left because we ask for 15
extra pixels on the top and left.
Unfortunately, SkImageDecoder will take our requested
sample size of 3, and then decide to use a sample size of
2. Not only will it scale the image by 2, but it will also
scale the border by 2. So while we are expecting pixel
data to begin at offset (5, 5) of the result bitmap, it
actually begins at offset (7, 7). Making things worse,
the pixels between (5, 5) and (7, 7) are uninitialized,
causing problems on Gold.
Options for fixing this include:
(1) Not testing decodes with a border.
(2) Changing the test to check the size of the output
bitmap.
(3) Disable the tests.
I think it's best to just disable these tests. We know
they don't work, so why do we need to see the results on
Gold?
BUG=skia:4319
Review URL: https://codereview.chromium.org/1313233007
These extra outputs were caused by recent changes to
push_codec_srcs.
https://codereview.chromium.org/1327433003/
*** First, I would argue that we do not want to test
"native" modes (ex: codec, scanline, etc) to scales
that require sampling (ex: 0.1, 0.2, etc). Right now,
we are trying to scale jpegs to 0.1, settling for 0.125
as the closest option, and then trying to compare the
0.125 scaled image to the actual 0.1 scaled image in
Gold.
*** Second, I messed up and caused our test setup to
try to decode to kIndex8 and kGray8 "always" instead
of only when it is recommended. The bad effect of this
happens because we can decode jpegs to kGray8 even if
they are color images. Right now in Gold, we have a
bunch of untriaged gray versions of color images.
The second issue would have been caught if we signaled
a fatal failure for invalid conversions. Maybe we should
look into this now that 565 is supported everywhere?
BUG=skia:
Review URL: https://codereview.chromium.org/1314163007
