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
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
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
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
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
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
*** Add CodecMode and ScaledCodecMode (in place of
NormalMode), so now we test SkCodec's getPixels() and
SkScaledCodec's getPixels()
*** Don't attempt to test scanline and codec modes using
the dimensions that were recommended for SkScaledCodec.
*** Change tags so that each scale gets its own output
folder.
TODO: Make ScanlineMode and ScanlineSubsetMode support
kOutOfOrder etc. I think this belongs with the gif CL -
I don't want to add test modes that we don't run yet.
BUG=skia:4202
BUG=skia:4238
Review URL: https://codereview.chromium.org/1327433003
Unfortunately, immintrin.h (which is also included by SkTypes)
includes xmmintrin.h which includes mm_malloc.h which includes
stdlib.h for malloc even though, from the implementation, it is
difficult to see why.
Fortunately, arm_neon.h does not seem to be involved in such
shenanigans, so building for Android will keep things sane.
TBR=reed@google.com
Doesn't change Skia API, just moves an include.
Review URL: https://codereview.chromium.org/1313203003
I suspect we might be doing some funky /n -> /r/n translations without 'b'.
This kills the PNG.
BUG=skia:
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/1303063008
Reason for revert:
derek + Test-Win8-MSVC-ShuttleB-CPU-AVX2-x86_64-Debug
Original issue's description:
> Have DM manually encode its .png outputs.
>
> This eliminates some variability on various axes: different PNG encoders, different libpng versions, different formats (RGB, indexed), different unpremultiplication, different sRGB tags.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/3cc0dfffb70c0bd08ed8899efcd2e98da86a6ec7TBR=stephana@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1297383002
This eliminates some variability on various axes: different PNG encoders, different libpng versions, different formats (RGB, indexed), different unpremultiplication, different sRGB tags.
BUG=skia:
Review URL: https://codereview.chromium.org/1304443002
Add more swizzling functions for swizzling to 565. Much of this
code was revived from crrev.com/1055743003 (for BMP). Also added
swizzling functions for WBMP.
Consolidate the static function conversion_possible.
In SkCodec::getPixels, check that the alphatype corresponds to the
colorType. This prevents requesting 565 + non-opaque.
In SkIcoCodec, report that the image is unpremul (instead of
whatever the largest embedded codec thinks), but modify the
requested info to have the alpha type expected/required by the
embedded codec.
Add tests for decoding to 565.
BUG=skia:3257
BUG=skia:3683
Review URL: https://codereview.chromium.org/1277213002
libwebp has a fix for [1]. Update to the commit that contains the fix.
Update libwebp.gypi, corresponding to libwebp's latest makefile.
Turn back on DM testing for scaled webp, now that it should no longer
use uninitialized memory.
Fix a warning in config.h
[1] https://code.google.com/p/webp/issues/detail?id=254
BUG=skia:4038
Review URL: https://codereview.chromium.org/1280073002
The decoding tests can now veto indirect sinks like pipe-8888.
This moves Sink type detection from automatic to explicit; I can't think of any
way to automatically differentiate pipe-8888 from 8888 based only on the
output. (They should ideally be identical, after all.)
BUG=skia:4138
Review URL: https://codereview.chromium.org/1263113002
This breaks Sinks down into three auto-detected types:
- GPU: anything that requests to be run in the GPU enclave
- Vector: anything that writes to the stream instead of the bitmap
- Raster: everything else
Some examples: gpu -> GPU, msaa16 -> GPU, 8888 -> raster, pdf -> vector,
svg -> vector, pipe-8888 -> raster, tiles_rt-gpu -> GPU
This lets image decoding sinks veto non-raster backends explicitly,
and can let particular GMs veto GPU or non-GPU sinks as they like.
BUG=skia:
Review URL: https://codereview.chromium.org/1239953004
This allows codecs that support subsets natively (i.e. WEBP) to do so.
Add a field on SkCodec::Options representing the subset.
Add a method on SkCodec to find a valid subset which approximately
matches a desired subset.
Implement subset decodes in SkWebpCodec.
Add a test in DM for decoding subsets.
Notice that we only start on even boundaries. This is due to the
way libwebp's API works. SkWEBPImageDecoder does not take this into
account, which results in visual artifacts.
FIXME: Subsets with scaling are not pixel identical, but close. (This
may be fine, though - they are not perceptually different. We'll just
need to mark another set of images in gold as valid, once
https://skbug.com/4038 is fixed, so we can tests scaled webp without
generating new images on each run.)
Review URL: https://codereview.chromium.org/1240143002
Scaling webp ends triggers warnings on our valgrind bot. It also results in
generating many images in Skia Gold that look mostly the same except
for a few pixels along the right edge.
BUG=skia:4038
Review URL: https://codereview.chromium.org/1227843005
We name our .pngs by pixel hashes for gold. For 8888 images, we're hashing
SkPMColors, which have platform-dependent order: BGRA on Linux and Windows,
RGBA otherwise. This means we can end up with pixel-identical pngs with
different hashes, which is confusing.
This CL standardizes on RGBA for 8888 configs, arbitrarily chosen so that
Android ends up a no-op. Long-term, this should eliminate most of the
0-pixel-diff problems we see on gold.skia.org. There are other ways to end up
with the same .png from different SkBitmaps (think, red 565 square vs. red 8888
square) but they're rather less common / likely.
This will temporarily create a giant 0-pixel-diff problem on gold.skia.org.
Any Linux or Windows images which are not already pixel-identical to a Mac or
Android image should show up as untriaged hashes that are pixel-identical to
their version just before landing (we're only changing the hash, not the .png).
This means anything vaguely platform dependent (fonts, GPUs) will probably show
up as needing a triage but with a zero diff from a previous image.
If this goes well, we might do the same for 565. Just want to leave them out
for now to cut down on the triaging I need to do in one go.
BUG=skia:
Review URL: https://codereview.chromium.org/1226933005
Mangle external function names to avoid conflict with libjpeg
Take advantage of direct color conversion (RGBA, BGRA, 565)
Prepare to use jpeg_skip_scanlines (when it is upstreamed)
BUG=skia:
Review URL: https://codereview.chromium.org/1180983002
Based on SkImageDecoder_libwebp.
TODO:
Support YUV? (Longer term - may influence our API for SkImageGenerator)
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044433002
This experiment replaces the label used in the aaxfermodes gm with
aliased text generated from paths common to all platforms.
Since there is no way today to generate all dm output from trybots,
this will be checked in to confirm that this strategy provides simpler
output across devices.
This does not introduce a new public interface; instead, dm uses
a extern backdoor to install the SkTypeface::CreateFromName
handler.
Review URL: https://codereview.chromium.org/1163283002
kScanline_Subset_Mode decodes the image in subsets using a
scanline decoder.
The number of subsets can be specified by changing the constant divisor.
The number of subsets is equal to divisor*divisor.
Review URL: https://codereview.chromium.org/1157153003
If so, let's do it this way so it works for all source types and doesn't need
to be chosen at compile time.
BUG=skia:
Review URL: https://codereview.chromium.org/1129693003
Will use this to test the other CL that adds small SkPicture implementations.
Not quite sure why patch_primitive doesn't draw the same in 8888 and sp-8888, but everything else does, so I'm not going to let that hold me back for now.
BUG=skia:
Review URL: https://codereview.chromium.org/1126613005
This requires we remove NVPR from the default set of configs, as we only find
out at runtime that it's not available. All the other defaults will either be
compiled in and supported, or not compiled in and non-fatally skipped as
unknown configs.
BUG=skia:
Review URL: https://codereview.chromium.org/1100773003
Enables basic decoding for jpegs
Includes rewinding
565, YUV, and Jpeg encoding are not yet implemented
BUG=skia:3257
Review URL: https://codereview.chromium.org/1076923002
We may want to enable swizzles to 565
for images that are encoded in a format
similar to 565, however, we do not want
to take images that decode naturally to
kN32 and then convert them to 565.
***Enable swizzles to kIndex_8. For images
encoded in a color table format, we suggest
that they be decoded to kIndex_8. When we
decode, we only allow conversion to kIndex_8
if it matches the suggested color type (except
wbmp which seems good as is).
***Modify dm to test images that decode to
kIndex_8.
BUG=skia:3257
BUG=skia:3440
Review URL: https://codereview.chromium.org/1055743003
I'm going to start hacking on SkCanvas a bit to allow a fast reset method,
and I want to have some testing checking me.
BUG=skia:
Review URL: https://codereview.chromium.org/1062043004
The file is expected to contain a list of strings. If the hash for
any result is in this file, don't write an image for it.
BUG=skia:3521
Review URL: https://codereview.chromium.org/1059363002
- By default, use new SkGoodHash to hash keys, which is:
* for 4 byte values, use SkChecksum::Mix,
* for SkStrings, use SkChecksum::Murmur3 on the data,
* for other structs, shallow hash the struct with Murmur3.
- Expand SkChecksum::Murmur3 to support non-4-byte-aligned data.
- Add const foreach() methods.
- Have foreach() take a functor, which allows lambdas.
BUG=skia:
Review URL: https://codereview.chromium.org/1021033002
Rather than making SkCodec an option instead of SkImageDecoder,
create a separate CodecSrc. This allows us to compare the two.
For both CodecSrc and ImageSrc, do not decode to a gpu backend.
BUG=skia:3475
Review URL: https://codereview.chromium.org/978823002
Seems strictly more useful.
This implements Mac and Windows, which seemed easy. Don't know how to do this on Linux yet.
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.9-MacMini6.2-HD4000-x86_64-Debug-Trybot
NOTREECHECKS=true
TBR=halcanary@google.com
Review URL: https://codereview.chromium.org/990723002
In non-verbose mode, these notes will spin away too fast to read anyway,
unless they're so long they end up leaving junk on the terminal.
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/989083002
Tasks that produce a non-fatal error will bail out before writing their output to
disk and hash to dm.json, but not count as failures.
This also makes true failures bail out before writing their results. If the DM
program failed, we probably don't want to triage that image result.
We use this new feature first to skip image subset decoding when we detect it's
not supported. Here's a snippet of an example run, where in this case only
.webp are subset decodable:
...
( 15MB 12) 172µs 8888 subset color_wheel.jpg (skipped: Subset decoding not supported.)
( 15MB 11) 9.05ms 8888 subset randPixels.webp
( 16MB 10) 863µs 8888 subset baby_tux.png (skipped: Subset decoding not supported.)
...
Only outputs corresponding to the .webp show up, both on disk and in the .json.
BUG=skia:
Review URL: https://codereview.chromium.org/980333002
Make a Via for DM which transforms a set of draws to be more like what
we'd see through the Android Framework's HWUI API. Only built inside
Android's framework because we depend on HWUI classes for half of
those transformations.
Tested with --config androidsdk-8888 and --config androidsdk-hwui.
R=djsollen@google.com,mtklein@google.com,reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/974913002
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
Review URL: https://codereview.chromium.org/963953002
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/963953002
Not enabled by default, but this should get you SKPs, GMs etc for free to play with.
$ out/Debug/dm -w svgs --src gm skp --config svg
BUG=skia:
Review URL: https://codereview.chromium.org/892693002
I had some suggestions on the subset CL, and took the opportunity to rebase it
against head and merge in the other color type CL.
BUG=skia:
Review URL: https://codereview.chromium.org/893703002
This way if a bot crashes, we might get some partial results in gold rather
than none. We do the same sort of thing in nanobench for perf.
BUG=skia:3255
Review URL: https://codereview.chromium.org/872443003
This basically takes out the Windows-only hacks and promotes them to
cross-platform behavior driven by --gpu_threading.
- When --gpu_threading is false (the default), this puts GPU tasks and tests
together in the same GPU enclave. They all run serially.
- When --gpu_threading is true, both the tests and the tasks run totally
independently, just like the thread-safe CPU-bound work.
BUG=skia:3255
Review URL: https://codereview.chromium.org/847273005
SkDeferredCanvas uses a simple pipe: no cross-process, no shared-address, etc.
(see src/utils/SkDeferredCanvas.cpp:306).
We could just remove these modes from the bot configs, but I'd like to take the
opportunity to simplify the DM code too. I'll happily volunteer to put things
back should we decide we want to test these modes.
BUG=skia:
Review URL: https://codereview.chromium.org/861303003
This will hold us closer to the principle that the test name (and only the test
name) should correspond to expected output. By the same reasoning, mix in the
number of subsets: if that changes, the expected output also changes.
BUG=skia:3255
Review URL: https://codereview.chromium.org/863723002
skiatest::Test class is now a simple struct. Some
functionalty, such as counting errors or timing is now
handled elsewhere.
skiatest:Reporter is now a simpler abstract class. The two
implementations handle test errors.
DM and pathops_unittest updated.
Review URL: https://codereview.chromium.org/830513004
