Make GrProgramsTest check how many texture coordinate sets are
available and select random effects up until the amount runs out.
Otherwise, following effect sequence would fail the shader compilation
when Skia is compiled with nv_path_rendering on (eg. when fixed
function codepath is used):
* Stage 0: TextureDomain (1 texcoord)
* Stage 1: Convolution (1 texcoord)
* Stage 2: Bitmap Alpha Threshold (2 texcoords)
* Stage 3: DisplacementMap (2 texcoords)
* Stage 4: Config Conversion (1 texcoords)
* Stage 5: Two-Point Conical Gradient (2 texcoords)
This would use more texture coordinate sets than 8, which is fairly
common amount currently.
R=bsalomon@google.com, cdalton@nvidia.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/32403002
git-svn-id: http://skia.googlecode.com/svn/trunk@11881 2bbb7eff-a529-9590-31e7-b0007b416f81
This change removes sk_stdint.h since it is only needed for vs2008 and earlier.
This change removes SK_MMAP_SUPPORT define since it is no longer used.
This change removes the stdio.h include from SkTypes.h since on many systems
this is a very large header, few Skia files actually use it, it is
available everywhere standard, and SkDebugf should be used instead.
After this change there is no need for external users to put Skia's
include/config into their own list of includes, saving the headache
of having two header files of the same name and sometimes getting the
wrong one depending on include order.
R=bsalomon@google.com, djsollen@google.com
Review URL: https://codereview.chromium.org/27044002
git-svn-id: http://skia.googlecode.com/svn/trunk@11738 2bbb7eff-a529-9590-31e7-b0007b416f81
Add new runtime configuration variable,
images.gif.suppressDecoderWarnings, which suppresses warning and
errors from the GIF library. It defaults to "true", which is current
behavior.
(This setting can be changed by setting the environment variable
skia_images_gif_suppressDecoderWarnings="false".)
Some conditions which were errors before are now warnings:
- If the image width or height is greater than the GIF screen width or
height (respectively) we expand the screen to hold the image.
- If the offset of the image inside the screen would place the
image outside of the screen, we shift the image to fix this.
- If the image lacks a color table, we create a default color table.
- If the image is truncated, then the rest of the image is filled with
the fill color.
In all four cases, if images.gif.suppressDecoderWarnings is set to
false, then a warning message is printed via SkDebugf.
In the event of another kind of error, SkGIFImageDecoder::onDecode()
will still return false. But with this change, if
images.gif.suppressDecoderWarnings is set to false, a description of
the error is printed via SkDebugf.
Also, added a new unit test GifTest, which tests the deconing of both
good GIf files and corrupted files that should now work with this
change. This unit test is disabled on Win32, iOS, and Mac.
BUG=skia:1689
R=scroggo@google.com
Review URL: https://codereview.chromium.org/26743002
git-svn-id: http://skia.googlecode.com/svn/trunk@11734 2bbb7eff-a529-9590-31e7-b0007b416f81
I noticed SkMatrix <-> SkMatrix44 conversions were dropping the
perspective values on the floor. As we use SkMatrix44 heavily in
Chromium, I'm concerned this missing code will cause a bug eventually.
It should be correct to simply use the bottom row of the 4x4 matrix
excluding the third column.
Previously committed and reverted, second attempt with fix for
incorrect use of SkMScalar/SkScalar.
BUG=
R=reed@google.com, caryclark@google.com
Author: aelias@chromium.org
Review URL: https://codereview.chromium.org/25484006
git-svn-id: http://skia.googlecode.com/svn/trunk@11624 2bbb7eff-a529-9590-31e7-b0007b416f81
I noticed SkMatrix <-> SkMatrix44 conversions were dropping the
perspective values on the floor. As we use SkMatrix44 heavily in
Chromium, I'm concerned this missing code will cause a bug eventually.
It should be correct to simply use the bottom row of the 4x4 matrix
excluding the third column.
BUG=
R=reed@google.com
Author: aelias@chromium.org
Review URL: https://codereview.chromium.org/25484006
git-svn-id: http://skia.googlecode.com/svn/trunk@11622 2bbb7eff-a529-9590-31e7-b0007b416f81
This change address what happens when a jpeg is partially downloaded
before failing. Many browsers will render it anyway: we want Skia to
do the same. The JpegTest takes a perfectly cromulent jpeg file and
only passes into the ImageDecoder the first half of the image. We
then verify that the image decoder returns a valid bitmap of the
correct dimensions.
We also fixed some png library errors, including issue 1691.
Also, suppressed the majority of warnings from using libpng and
libjpeg. By default, most warnings are *not* suppressed in debug mode.
If you have a debug binary and wish to suppress warnings, set the
following environment variables to true
skia_images_png_suppressDecoderWarnings
skia_images_jpeg_suppressDecoderWarnings
or from within a program that links to Skia:
#if defined(SK_DEBUG)
#include "SkRTConf.h"
SK_CONF_SET("images.jpeg.suppressDecoderWarnings", true);
SK_CONF_SET("images.png.suppressDecoderWarnings", true);
#endif
I tested this, before (control) and after these changes (test), on
364,295 skps from the cluster telemetry.
- number of errors+warnings in control = 2804
- number of errors+warnings fixed = 2283
- number of PNG verbosity fixed = 2152
- number of PNG error fixed = 4
- number of PNG segfault fixed = 3
- number of PNG errors changed to warnings = 62
- number of JPG verbosity fixed = 26
- number of JPG error fixed = 91
Not all errors and warning have been fixed.
These numbers were generated using the find_bad_images_in_skps.py
program. This program may be useful going forward for testing
image-decoding libraries on skp files from the cluster telemetry.
find_bad_images_in_skps.py depends on the test_image_decoder program,
which simply executes the SkImageDecoder::DecodeFile function and uses
its exit status to report success or failure.
BUG=skia:1649
BUG=skia:1691
BUG=skia:1680
R=scroggo@google.com
Review URL: https://codereview.chromium.org/24449003
git-svn-id: http://skia.googlecode.com/svn/trunk@11597 2bbb7eff-a529-9590-31e7-b0007b416f81
These guys are not heavily contended nor speed critical. No need for atomics,
plus this makes tsan stop complaining (correctly) about reading fNextIndex
unsafely in onEnd.
I took a look at failCount/fFailCount, which I think is safely atomic and quite
conveniently so: It's never read until all the threads which could possibly
increment it have terminated (except for the one where it was created,
obviously). We could guard it with a mutex too, but maybe we can let this one
slide.
BUG=
R=bungeman@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/25357002
git-svn-id: http://skia.googlecode.com/svn/trunk@11561 2bbb7eff-a529-9590-31e7-b0007b416f81
