Tested in Mozilla source tree. I tried to use skia build system, but it's up to the task for cross compilation.
SkHRESULT.cpp - Use proper file name (that matters on case sensitive OSes)
SkAtomics_win.h - Don't use pragma intrinsic on GCC (this causes massive warnings)
SkOSFile_win.cpp - This one is tricky. GCC doesn't allow (void*) casts in template argument constants and INVALID_HANDLE_VALUE looks like this:
((HANDLE)(LONG_PTR)-1)
where HANDLE is typedefed to void*. Changed the code to use LONG_PTR as template argument and cast it when needed.
BUG=skia:
R=bungeman@google.com, reed@google.com
Author: cjacek@gmail.com
Review URL: https://codereview.chromium.org/198643004
git-svn-id: http://skia.googlecode.com/svn/trunk@13862 2bbb7eff-a529-9590-31e7-b0007b416f81
When accessBitmap() is called on a GPU device which has deferred clear,
and no drawing has been done, force the clear before returning the
bitmap.
This is covered by the top right test case in the imagefilterscropexpand
GM, where an offset image filter is drawn but the resulting bitmap is
cropped out, resulting in no drawing to the offscreen. It should be
empty, but without this fix it results in garbage (previous scratch
texture contents).
BUG=skia:
R=bsalomon@google.com
Review URL: https://codereview.chromium.org/204903002
git-svn-id: http://skia.googlecode.com/svn/trunk@13860 2bbb7eff-a529-9590-31e7-b0007b416f81
For the "pull forward" task I will be comparing the two cases:
analyze the whole skp and use the BBH information
analyze only the active portion of the skp
In the first case we need a way to get the BBH information out of the picture in order to extract the relevant portions of the whole-skp analysis. This adds caching of the active ops so that work isn't duplicated between when the optimization path queries for that information and when the usual draw path queries for it.
R=reed@google.com, bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/195793010
git-svn-id: http://skia.googlecode.com/svn/trunk@13836 2bbb7eff-a529-9590-31e7-b0007b416f81
NOTE: this patch set is based on https://codereview.chromium.org/189913021/,
and needs that patch to land first.
Until now, crop rects in Skia have only been able to reduce
the size of the destination bounds, but not expand them.
SVG semantics require the latter as well. The heart of
the change is in applyCropRect(), which now assigns each
edge, instead of doing an intersection with the crop rect.
In order to support this (and still work well with tiled
drawing) we need to clip the resulting crop rect to the
clipping region of the filters. This uses the Context struct
previously landed from https://codereview.chromium.org/189913021/.
Many of the pixel loops are not yet ready to handle a
destination rect larger than the source rect. So we provide
a convenience version of applyCropRect() which creates an
offscreen and pads it out with transparent black. Once the
pixel loops and shaders have been fixed to support larger
destination bounds, they should be switched back to the
non-drawing version of applyCropRect().
BUG=skia:
R=bsalomon@google.com, reed@google.com
Committed: https://code.google.com/p/skia/source/detail?r=13805
Review URL: https://codereview.chromium.org/198003008
git-svn-id: http://skia.googlecode.com/svn/trunk@13809 2bbb7eff-a529-9590-31e7-b0007b416f81
NOTE: this patch set is based on https://codereview.chromium.org/189913021/,
and needs that patch to land first.
Until now, crop rects in Skia have only been able to reduce
the size of the destination bounds, but not expand them.
SVG semantics require the latter as well. The heart of
the change is in applyCropRect(), which now assigns each
edge, instead of doing an intersection with the crop rect.
In order to support this (and still work well with tiled
drawing) we need to clip the resulting crop rect to the
clipping region of the filters. This uses the Context struct
previously landed from https://codereview.chromium.org/189913021/.
Many of the pixel loops are not yet ready to handle a
destination rect larger than the source rect. So we provide
a convenience version of applyCropRect() which creates an
offscreen and pads it out with transparent black. Once the
pixel loops and shaders have been fixed to support larger
destination bounds, they should be switched back to the
non-drawing version of applyCropRect().
BUG=skia:
R=bsalomon@google.com, reed@google.com
Review URL: https://codereview.chromium.org/198003008
git-svn-id: http://skia.googlecode.com/svn/trunk@13805 2bbb7eff-a529-9590-31e7-b0007b416f81
Some upcoming work (support for expanding crop rects) requires
the clip bounds to be available during filter traversal. This change
replaces the SkMatrix parameter in the onFilterImage() traversals
with a Context parameter. It contains the CTM, as well as the clip
bounds.
BUG=skia:
R=reed@google.com
Review URL: https://codereview.chromium.org/189913021
git-svn-id: http://skia.googlecode.com/svn/trunk@13803 2bbb7eff-a529-9590-31e7-b0007b416f81
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
