lock pixels when we extract alpha
disabling hinting when linear-text is set
git-svn-id: http://skia.googlecode.com/svn/trunk@333 2bbb7eff-a529-9590-31e7-b0007b416f81
- copyTo() now preserves isOpaqueness, and BitmapCopyTest tests it
- bitmap shader doesn't claim to have shadespan16 if dithering is on, since its
sampler doesn't auto-dither (note that gradients do auto-dither in their
16bit sampler)
- blitter setup just relies on the shader to report if its 16bit sampler can be
called (allowing gradients to say yes regardless of dither, but bitmaps to say
no if dithering is on)
git-svn-id: http://skia.googlecode.com/svn/trunk@331 2bbb7eff-a529-9590-31e7-b0007b416f81
- smulbb is only on ARMv5TE and above (p316, ARM Architecture Reference Manual)
- an empty clobber list causes a compiler error with my compiler, gcc-4.3.2
Patch by Joel Stanley <joel@jms.id.au>
Review URL: http://codereview.appspot.com/96165
git-svn-id: http://skia.googlecode.com/svn/trunk@329 2bbb7eff-a529-9590-31e7-b0007b416f81
all slides
add beforeChild/afterChild methods for parents to wack the canvas before/after
it draws. These are called after the std child-view translate and clip, unlike
beforeChildren/afterChildren
git-svn-id: http://skia.googlecode.com/svn/trunk@324 2bbb7eff-a529-9590-31e7-b0007b416f81
perspective case when affine would have been enough (and lots faster).
git-svn-id: http://skia.googlecode.com/svn/trunk@323 2bbb7eff-a529-9590-31e7-b0007b416f81
fix bug in quad loop of fill_sequential where we were going one quad too far.
git-svn-id: http://skia.googlecode.com/svn/trunk@322 2bbb7eff-a529-9590-31e7-b0007b416f81
operator==, given that we may be padded and not know how to init those pad bytes
git-svn-id: http://skia.googlecode.com/svn/trunk@321 2bbb7eff-a529-9590-31e7-b0007b416f81
(somewhat) than their scale counterparts, but are also numerically exact for
any size bitmaps. The scale versions, because they operate in a scaled 65535
space, are not always exact for large images (due to SK_Fixed1 / width) loss of
bits
git-svn-id: http://skia.googlecode.com/svn/trunk@320 2bbb7eff-a529-9590-31e7-b0007b416f81
Because the underlying mask extends a pixel to the left and right (or
top and bottom on vertical LCDs), the requested pixel can actaully be
one pixel outside the bounds, thus this assertion is incorrect.
http://codereview.appspot.com/105077
git-svn-id: http://skia.googlecode.com/svn/trunk@312 2bbb7eff-a529-9590-31e7-b0007b416f81
- remove neon-specific functions that were not faster than the C version
- move the neon filter function to its own header, so it could be use in more places
git-svn-id: http://skia.googlecode.com/svn/trunk@309 2bbb7eff-a529-9590-31e7-b0007b416f81
add -match foo to restrict the benchmarks to those whose names match foo
git-svn-id: http://skia.googlecode.com/svn/trunk@305 2bbb7eff-a529-9590-31e7-b0007b416f81
r291 added support for building on platforms where subpixel support
has been compiled out of FreeType. However, it turns out that there is
a common situation in which we build on platforms with subpixel
support, but have to run without it: people downloading Chromium from
the buildbots.
Because we this, we need a runtime solution. Modifying the conversion
routines for this seems suboptimal because the extra branches will
slow down everyone. So we probe subpixel support at runtime by trying
to install a low-pass filter. If we fail at this, then we map all the
SkScalerContext::Rec structures to remove subpixel mode.
http://codereview.appspot.com/98057
git-svn-id: http://skia.googlecode.com/svn/trunk@293 2bbb7eff-a529-9590-31e7-b0007b416f81
This reverts commit r291. It will be replaced with another solution in the next
commit.
git-svn-id: http://skia.googlecode.com/svn/trunk@292 2bbb7eff-a529-9590-31e7-b0007b416f81
On Fedora, at least, FreeType is built without subpixel support. It
tries to simulate subpixel mode by replicating the gray-values three
times. However, it fails to simulate the actions of the low-pass
filter and so doesn't add border around the glyphs. This patch adds a
compile-time constant, which is the number of bytes of filter border.
If this value is zero (because FreeType is simulating subpixel
support), then we add a transparent border ourselves when transforming
from FreeType rendered glyphs to masks.
http://codereview.appspot.com/96171
git-svn-id: http://skia.googlecode.com/svn/trunk@291 2bbb7eff-a529-9590-31e7-b0007b416f81
Now that Chrome is rendering subpixel text, I was able to try running
the renderer process under valgrind, which turned up a number of
issues.
First, I was calculating the stride of vertical LCD glyphs wrong
(typo).
Secondly, I was going horribly wrong when a glyph was being blitted at
the edge of a bitmap. I suspected something was wrong with the code,
but I wasn't clear enough with the structure of the code when writing
it to figure out what the correct solution was.
http://codereview.appspot.com/97059
git-svn-id: http://skia.googlecode.com/svn/trunk@284 2bbb7eff-a529-9590-31e7-b0007b416f81
