Also implement SkGPipeCanvas::drawBitmapMatrix, and
create a GM to make sure it works properly.
Use a flag instead of writing a bool for determining whether
drawBitmap_ has a paint and whether drawBitmapRect has a source
rectangle.
BUG=
TEST=drawbitmapmatrix GM
Review URL: https://codereview.appspot.com/6450053
git-svn-id: http://skia.googlecode.com/svn/trunk@4828 2bbb7eff-a529-9590-31e7-b0007b416f81
Also make SkGPipeController ref the recording canvas to ensure that
objects used by SkGPipeCanvas (e.g. SharedHeap and fTypefaceSet, which
hold references to objects to which pointers are written to the stream)
survive to be played back even if SkGPipeWriter.endRecording() is called.
BUG=
TEST=TypefaceGM
Review URL: https://codereview.appspot.com/6447055
git-svn-id: http://skia.googlecode.com/svn/trunk@4817 2bbb7eff-a529-9590-31e7-b0007b416f81
Prior to this CL mutable bitmaps only saved a copy of their pixels
if a flag was set at recording time. That flag has been removed
and the default behavior when recording a mutable bitmap is to
make a copy of it's pixels. This is the only way to ensure that
the pixels are not manipulated before we playback their contents.
However, enabling this behavior breaks the recording of extracted
bitmaps in SkPicture. This is because we currently cache bitmaps
within a picture based only on their pixelRef. This results in
false positive cache hit when drawing an extracted bitmap as it
shares a pixelRef with its orginating bitmap. Therefore we must
update the index of the bitmap cache to be both the pixelRef AND
the size and offset of the bitmap using those pixels.
BUG=
TEST=extractbitmap.cpp
Review URL: https://codereview.appspot.com/6439043
git-svn-id: http://skia.googlecode.com/svn/trunk@4809 2bbb7eff-a529-9590-31e7-b0007b416f81
Also tidied up Gr gradient implementation constructors, to take the appropriate SkGradientShaderBase subclass, and where necessary (namely 2pt radial/conical) made them obtain extra parameters from that object, rather than passing them in in addition to it.
Review URL: https://codereview.appspot.com/6449057
git-svn-id: http://skia.googlecode.com/svn/trunk@4808 2bbb7eff-a529-9590-31e7-b0007b416f81
Besides the raw processing improvement provided by Neon, the code uses memory
preteches (pld) which seem to improve performance greatly when dealing with
very large counts.
This was tested using bench where color32 accounts for the majority of the
workload:
bench -match rects_1 -config 8888 -repeat 500 -forceBlend 1
(the forceBlend is there so that the Color32 code does not go through the
special cases where alpha == 0xFF as it would transform color32 into
a sk_memset32.
Numbers averaged over 3 runs:
bench name | Before | Neon, no pld | Neon with pld | full boost
rrects_1 | 153.9 | 128.3 | 92 | 1.66x
rects_1_stroke_4| 32.8 | 31.4 | 28.45 | 1.15x
rects_1 | 125.35 | 97.2 | 63.59 | 1.97x
Credits: various googletv team members.
Committed on behalf of evannier.
Review URL: http://codereview.appspot.com/5569077/
git-svn-id: http://skia.googlecode.com/svn/trunk@4779 2bbb7eff-a529-9590-31e7-b0007b416f81
In the non-Neon optimized fallback in SCALE_NOFILTER_NAME() the pixels
are first processed in groups of 4, followed by the final remaining 0-3
pixels depending on the span length.
Currently the remaining span length (0-3) pixels is incorrectly
calculated as count - count / 4. This generally causes the function to
access outside the bounds of the input and/or output bitmaps.
The correct formula is count % 4, because all the full multiples of 4
pixels have been processed and only the remainder remains.
Bug spotted by Xianzhu Wang.
TEST=None, because this part of the code isn't actually even being compiled due
to the !defined(__ARM_HAVE_NEON) guard at the top of the file. It was compiled
in by mistake in Chrome for Android, which is how this bug was spotted.
Review URL: https://codereview.appspot.com/6441050
git-svn-id: http://skia.googlecode.com/svn/trunk@4777 2bbb7eff-a529-9590-31e7-b0007b416f81
