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
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
