GitLab

GR_GL_IGNORE_ES3_MSAA is a workaround for older versions of Chrome, and
M33 (the version we're using) no longer needs it.

BUG:13246311
Change-Id: Ib3cffe72b0b0b0e1fe1b441f3f716dd62ae17ad3

These optimizations are disabled in chromium m33, so disable them in
Android's build of Skia, against which chromium/webview will link.

BUG:13246311
Change-Id: I8e64dea2d232a6b3616c225f1cd269f086b056e3

This version adds SkRefCnt::deref(). This allows chromium on Android
to build against the system version of Skia, since chromium requires
this function.

BUG:13246311
Change-Id: I988ef1f76e4e10918ca896e4488d65ccc94837c6

Merge fix for nativeDecodeFileDescriptor into MR2.
BUG:13191516

Original CL below:

Allow buffered stream to work with an offset.

If the stream being buffered is buffered from somewhere other than
the start, the SkFrontBufferedStream needs to take that into account
when reporting its length.

Required for https://googleplex-android-review.googlesource.com/#/c/415165/1
in frameworks/base to work.

BUG:12807677
BUG:12895876
Cherry-pick from: I675397f5cebb7c7d8bc9f76acb5265d7209cbbc2

Change-Id: Ia9aa7451fd6f72f0f5c8ba68199f0a74c0475178

SkMorphologyGetPlatformProc is defined in both SkMorphology_opts_none
and opts_check_arm, so don't build both files.

Bug: 13246311
Change-Id: I06e75c2a99a8820b79b1c068b136349027814ae3

Bug: 13246311

Change-Id: I6cd6a7dd95f2ca693412dbf71cc858c89480f990

This CL was generated using "svn diff -r12932:12963" on the skia branch /chrome/m33_1750

------------------------------------------------------------------------
r12963 | fmalita@google.com | 2014-01-08 12:17:22 -0500 (Wed, 08 Jan 2014) | 1 line

Cherrypick r12846 into m33_1750 for http://crbug.com/330293
------------------------------------------------------------------------
r12945 | sugoi@google.com | 2014-01-07 13:15:39 -0500 (Tue, 07 Jan 2014) | 1 line

cherrypick changes into branch m33_1750 to fix http://crbug.com/329254
------------------------------------------------------------------------
r12934 | vandebo@chromium.org | 2014-01-06 18:40:00 -0500 (Mon, 06 Jan 2014) | 17 lines

Merge 12729 "[PDF] Fix clipping in xfermode improvement."

> [PDF] Fix clipping in xfermode improvement.
>
> In some cases, the wrong clip (src clip instead of initial clip) was used.
> Switch almost exclusively to initial clip because it is safe and generates a smaller result.
>
> BUG=chromium:328009
> R=reed@google.com, bungeman@google.com
>
> Author: vandebo@chromium.org
>
> Review URL: https://codereview.chromium.org/116423004

TBR=vandebo@chromium.org

Review URL: https://codereview.chromium.org/125293004
------------------------------------------------------------------------

Change-Id: I1d7b49c7dbd32f8d024492d4576879dbecb1d19c

This is a modified cherry-pick of https://code.google.com/p/skia/source/detail?r=13503

bug: 12968474
Change-Id: I245eea4f05f402ca24849d5d2fe354c69526d03d

Conflicts:
	include/core/SkDraw.h
	include/pdf/SkPDFDevice.h
	include/utils/SkCanvasStateUtils.h
	include/utils/SkFrontBufferedStream.h
	src/core/SkDevice.cpp
	src/core/SkDeviceLooper.cpp
	src/core/SkDeviceLooper.h
	src/core/SkRRect.cpp
	src/doc/SkDocument_PDF.cpp
	src/effects/SkBlurMaskFilter.cpp
	src/fonts/SkFontMgr_fontconfig.cpp
	src/gpu/GrAAHairLinePathRenderer.cpp
	src/gpu/GrAAHairLinePathRenderer.h
	src/gpu/GrTextContext.cpp
	src/images/SkImageDecoder_libpng.cpp
	src/images/SkScaledBitmapSampler.cpp
	src/images/SkScaledBitmapSampler.h
	src/pdf/SkPDFDevice.cpp
	src/pdf/SkPDFDeviceFlattener.cpp
	src/ports/SkFontConfigInterface_android.cpp
	src/ports/SkFontHost_FreeType.cpp
	src/ports/SkFontHost_FreeType_common.cpp
	src/utils/SkCanvasStack.cpp
	src/utils/SkCanvasStack.h
	src/utils/SkCanvasStateUtils.cpp
	src/utils/SkDeferredCanvas.cpp
	src/utils/SkFrontBufferedStream.cpp
	src/utils/SkPictureUtils.cpp

Change-Id: Ice86d9769ed99f804932d8839acfdea695cb6d28

Change-Id: I0470d8e53bf019f410509180b95950f20f98a5e8

Change-Id: Ia710b27d97e938df06014b7b61a3767bd3be1eb5

Recent changes to SkBitmapDevice modified ::drawRRect() to take
an optimized drawing case. Some subclasses of SkBitmapDevice were
depending on the old behavior of calling ::drawPath(). Since they
do not draw, attempting to take the drawing path can cause problems.
For these subclasses, call drawPath() in the subclass.

Cherry-pick of https://code.google.com/p/skia/source/detail?r=12247 in Skia.

BUG:11648093
Change-Id: Ie2173907c58c36b28855aba5a71b7ad676cc543e

Cherry-pick of Skia from https://codereview.chromium.org/65723005/

Found by our valgrind bot:

63,808 bytes in 126 blocks are definitely lost in loss record 76 of 76
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x52C126: sk_malloc_flags(unsigned long, unsigned int) (SkMemory_malloc.cpp:45)
by 0x52C157: sk_malloc_throw(unsigned long) (SkMemory_malloc.cpp:31)
by 0x42A9B2: SkMask::AllocImage(unsigned long) (SkMask.cpp:40)
by 0x5BD349: prepare_to_draw_into_mask(SkRect const&, SkMask*) (SkBlurMaskFilter.cpp:170)
by 0x5BEDC6: SkBlurMaskFilterImpl::filterRRectToNine(SkRRect const&, SkMatrix const&, SkIRect const&, SkMaskFilter::NinePatch*) const (SkBlurMaskFilter.cpp:181)
by 0x42B604: SkMaskFilter::filterRRect(SkRRect const&, SkMatrix const&, SkRasterClip const&, SkBounder*, SkBlitter*, SkPaint::Style) const (SkMaskFilter.cpp:218)
by 0x42460E: SkDraw::drawRRect(SkRRect const&, SkPaint const&) const (SkDraw.cpp:1056)
by 0x413F9C: SkBitmapDevice::drawRRect(SkDraw const&, SkRRect const&, SkPaint const&) (SkBitmapDevice.cpp:235)
by 0x419D31: SkCanvas::drawRRect(SkRRect const&, SkPaint const&) (SkCanvas.cpp:1695)
by 0x43F865: SkPicturePlayback::draw(SkCanvas&, SkDrawPictureCallback*) (SkPicturePlayback.cpp:1001)
by 0x43BC1A: SkPicture::draw(SkCanvas*, SkDrawPictureCallback*) (SkPicture.cpp:261)
by 0x407D42: void sk_tools::DrawTileToCanvas<SkPicture>(SkCanvas*, SkRect const&, SkPicture*) (PictureRenderer.cpp:502)
by 0x4080BA: sk_tools::TiledPictureRenderer::render(SkString const*, SkBitmap**) (PictureRenderer.cpp:546)
by 0x4064EF: render_picture(SkString const&, SkString const*, sk_tools::PictureRenderer&, SkBitmap**) (render_pictures_main.cpp:193)
by 0x406637: render_picture(SkString const&, SkString const*, sk_tools::PictureRenderer&) (render_pictures_main.cpp:251)
by 0x406F50: tool_main(int, char**) (render_pictures_main.cpp:360)
by 0x407142: main (render_pictures_main.cpp:455)

BUG:11630753
Change-Id: Ie7792111449da3126a5e9e273e79bbb36481349c

Cherry pick of https://codereview.chromium.org/52703003/ in Skia.

Add SkRRect::transform.

Much like SkPath::transform, it transforms an SkRRect based on an
SkMatrix. Unlike SkPath::transform, it will fail for matrices that
contain perspective or skewing.

Cherry pick of https://codereview.chromium.org/48623006/ in Skia.

Add ability to ninepatch blurred rounded rectangle

Speed up drawing large blurry round rectangles by converting them to
nine patches.

SkDraw:
Add drawRRect.

SkBitmapDevice:
Call SkDraw::drawRRect instead of converting SkRRect to an SkPath.

SkMaskFilter/SkBlurMaskFilter:
Create a nine patch of a blurred round rect and draw it instead of
drawing the entire thing.

SkPDFDevice:
Override drawRRect to perform the old behavior in
SkBitmapDevice::drawRect.

BUG:11174385
Change-Id: I96e6bf50c1418f7df70681afee6e25be40615497

Cherry pick of https://code.google.com/p/skia/source/detail?r=12034 in Skia
[PDF] Improve complex xfer mode support.

Xfer mode applies only to the shape of the source drawing, not everything in the
clip as in currently implemented.  It's just that the current gm examples draw a
shape that fills the visible layer.

BUG:11477060

Change-Id: I9f82aeb09ead0d7e600590264a594262ec6c6282

From Skia's repo:

http://code.google.com/p/skia/source/detail?r=11751
Add SkPDFDeviceFlatenner which extends SkPDFDevice to add support
to flatten the path and the text when we have perspective. prepare
to deprecate SkPDFDevice constructor, and route gm and render_pdfs
to use SkDocument::Create pdf interface instead. - controlled by a
flag add comments where we are supposed to flatten other features
(paint, shaders, ... )

https://code.google.com/p/skia/source/detail?r=11822
Implement perspective for bitmaps in pdf.

https://code.google.com/p/skia/source/detail?r=11937
PDF: support perspective in simple shaders. (this version does not
work well with tilling)

BUG:11384071

Change-Id: I48ea88d231231215349f155d972c6b9e1e127c71

This captures revisions r11503 to r11657 (inclusive). This range appears
large, but covers a span of just 3 commits one of which has already been
cherry-picked into this repository.

bug: 10285384

Change-Id: I614888fe1b65f31a713a689ccb3a9db6265b60e8

cherry-pick of http://code.google.com/p/skia/source/detail?r=11472

bug: 11115961
Change-Id: I0ed8af0bdec006178e5e6bd1c0a0c4f1cb517961

cherry-pick of http://code.google.com/p/skia/source/detail?r=11641

bug: 11093744
Change-Id: I2efa84c612e5a790a61707eae7e078a3b8215e2e

Do not attempt to convert non gray PNG to A8.
For an A8 image, do not consider it opaque.

cherry-picked from https://codereview.chromium.org/24882002 in Skia:

Do not convert non gray PNG to A8.

If the user requested A8, but the source is not gray, switch to
ARGB8888.

cherry-picked from https://codereview.chromium.org/25726004 in Skia:

Fixes for decoding to A8.

src/images/SkImageDecoder_libpng.cpp:
A8 images are not opaque, so do not set the opaque flag.
This fixes a bug where copyTo does not work as expected (when
copying an A8 decoded image to ARGB_8888), leading to
a bitmap hash that does not represent the image correctly
(in skimage).

tools/skimage_main.cpp:
In write_bitmap, which is creating the image for visual comparison,
copy A8 to 8888, since A8 cannot be encoded.

In the section that tests reencoding, do not test reencoding A8,
which is known to not work.

BUG:9189955

Cherry-pick of https://code.google.com/p/skia/source/detail?r=11586

bug: 11001915
Change-Id: Id7e09ac0f9169601a0706266f0b4e39ad45b5e8b

Cherry-pick of https://code.google.com/p/skia/source/detail?r=11394

bug: 10653841
Change-Id: If50522fae5a8b749dbf97db8eca8c518cd710ebf

cherry-pick of http://code.google.com/p/skia/source/detail?r=11420

bug:10845219
Change-Id: I94b765a462521a17b4e432a639e3f1484cc180c3

Do not build bench which depends on more recent changes to
bench not included by android yet.

Change-Id: Icddcd60be3cb5f577378b0a82c8d0084fdebc498

Only implemented for PNG.

Add a getter and setter, and sets the default to false in the
constructor. Also copies the setting in copyFieldsToOther.

Fix an indpendent bug where fDitherImage was not being copied in
copyFieldsToOther.

In SkScaledBitmapSampler::begin, consolidate the settings passed in
by passing a const reference to the decoder. The decoder can be
referenced for its settings of dither, unpremultiplied, and now
skipping writing zeroes. Update callers to use the new API. In png
decoder, rather than passing around a pointer to an initial
read of getDitherImage, and potentially changing it, look at the
field on the decoder itself, and modify it directly. This is a
change in behavior - now if that same decoder is used to decode
a different image, the dither setting has changed. I think this is
okay because A) the typical use case is to use a new decoder for
each decode, B) we do not make any promises that a decode does not
change the decoder and C) it makes the code in SkScaledBitmapSampler
much cleaner.

In SkScaledBitmapScampler, add new row procs for skipping zeroes. Now
that choosing the row proc has five dimensions (src config, dst config,
dither, skip writing zeroes, unpremultiplied), use a new method: each
src/dst combination has a function for choosing the right proc depending
on the decoder.

SkScaledBitmapScampler::RowProc is now public for convenience.

Remove Sample_Gray_D8888_Unpremul, which is effectively no different
from Sample_Gray_D8888.

In cases where unpremultiplied was trivial, such as 565 and when
sampling from gray, decoding may now succeed.

Add a benchmark (currently disabled) for comparing the speed of skipping
writing zeroes versus not skipping. For this particular image, which is
mostly transparent pixels, normal decoding took about 3.6 milliseconds,
while skipping zeroes in the decode took only about 2.5 milliseconds
(this is on a Nexus 4). Presumably it would be slower on an image
with a small amount of transparency, but there will be no slowdown
for an image which reports that it has no transparency.

In SkImageRef_ashmem, always skip writing zeroes, since ashmem
memory is guaranteed to be initialized to 0.

Add a flag to skip writing zeroes in skimage.

Add a regression test for choosing the rowproc to ensure I did not
change any behavior accidentally.

BUG:10016979
Change-Id: I5986ae750b85a9c9d8e3cafeebe904910247de3b