- 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
before we turn it into a font-cache entry, for the cases where the scaler will
ignore and/or collapse certain feature requests (e.g. doesn't support all levels
of hinting)
git-svn-id: http://skia.googlecode.com/svn/trunk@283 2bbb7eff-a529-9590-31e7-b0007b416f81
feature (since we already have subpixel text support)
fix some debug-compile problems
update Makefile for lcd files
git-svn-id: http://skia.googlecode.com/svn/trunk@282 2bbb7eff-a529-9590-31e7-b0007b416f81
fix case where cubic is big/degenerate, and never returns a valid edge
git-svn-id: http://skia.googlecode.com/svn/trunk@280 2bbb7eff-a529-9590-31e7-b0007b416f81
This patch adds support for rendering subpixel glyphs (using
Freetype). In order to control this rendering see
SkPaint::setLCDRenderText in SkPaint.h.
To setup the LCD mode, see SkFontHost::SetSubpixelOrientation and
SkFontHost::SetSubpixelOrder in SkFontHost.h.
This patch also adds more fine grained control over hinting (again,
only for Freetype currently). One can now control the hinting with
SkPaint::setHinting.
git-svn-id: http://skia.googlecode.com/svn/trunk@275 2bbb7eff-a529-9590-31e7-b0007b416f81
this at least draws the right colors, since we're 565 and CG only supports 1555
(unless someone knows how to tell CG we're 565...)
Fix ws in picturerecord
Enable dither in sample gradients, so the 4444 case isn't so ugly
git-svn-id: http://skia.googlecode.com/svn/trunk@264 2bbb7eff-a529-9590-31e7-b0007b416f81
