History log of /haiku/src/servers/app/drawing/Painter/AGGTextRenderer.h
Revision Date Author Comments
# 91233f88 26-Feb-2014 Stephan Aßmus <superstippi@gmx.de>

Font: Work on support for spacing modes.

* Change default spacing to B_BITMAP_SPACING. The BeBook does not document
what the default spacing is, and I have no BeOS install handy to check.
However, I believe that B_BITMAP_SPACING is what should be the default,
since it gives the best visible result for the common use-case.
In terms of implementation, there is no change, since spacing was ignored
until now and the behavior was that of B_BITMAP_SPACING. This change could
however break BeOS apps which assume B_CHAR_SPACING is the default and don't
set it on new when they need it. Sample code in the BeBook however shows
setting B_CHAR_SPACING on a newly created BFont.
* Implement B_STRING_SPACING to do something sensible. The BeBook documentation
is completely vague in what it is actually supposed to do. Given the
possibilities of FreeType, I am implementing it to enable the use of
kerning. Kerning optimizes the spacing between two glyphs, for example, it
would decrease the spacing between "T" and "e" in the string "Test" for
our default font. Untested.


# b4671beb 06-Feb-2014 Stephan Aßmus <superstippi@gmx.de>

Regard Painter's transformation when rendering text.


# a2f075eb 28-Jan-2014 Stephan Aßmus <superstippi@gmx.de>

app_server: Support alpha masks for text rendering...

... both vector and bitmap based. Sub-pixel text rendering not yet handled,
I think the scanline is used differently in this case, in that three times the
horizontal resolution is used, while the alpha map doesn't match this
increase.


# 77e5acc0 15-Mar-2010 Stephan Aßmus <superstippi@gmx.de>

* Extended the BView drawing API by a DrawString() version that takes an array
of locations, one for each glyph.
* Added a test for the new functionality.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35865 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ff4aa6dc 09-Apr-2009 Stephan Aßmus <superstippi@gmx.de>

Style cleanup


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30065 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a4a780db 19-Jan-2009 Stephan Aßmus <superstippi@gmx.de>

Removed left over.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28969 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 59e13a3f 03-Aug-2008 Stephan Aßmus <superstippi@gmx.de>

Patch by Andrej Spielmann (GSoC):
* Simplified the subpixel related methods for the AGG "pixel format" template
interface, the ones for the solid cover simply pass through the existing
methods, so only one subpixel blending function is left which does the actual
work (this removes a lot of the previously added code)
* Implemented a new rasterizer based on the original AGG rasterizer which
implements subpixel anti-aliasing for any generic AGG vector pipelines. It
is now optionally used in Painter and AGGTextRenderer (for vector fonts, ie
rotated, sheared or big enough fonts) depending on the global subpixel
setting.
* Put all subpixel variables into the new GlobalSubpixelSettings.h|cpp
* Simplified DesktopSettings related classes a bit and renamed previous
FontSubpixelAntialiasing to just SubpixelAntialiasing.
* The private libbe functions for subpixel related settings moved from Font.cpp
to InterfaceDefs.cpp where other such functions live. They are not related
to fonts only anymore.
* Removed the subpixel related settings again from the Fonts preflet and added
them to the Appearance preflet instead.

All of the above implements subpixel anti-aliasing on a global scale, which
to my knowledge no other OS is doing at the moment. Any vector rendering
can optionally use subpixel anti-aliasing in Haiku now. The bitmap cached fonts
are still affected by the Freetype complile time #define to enable the patented
subpixel rasterization (three times wide glyphs). Vector fonts and shapes are
not affected though at the moment.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26755 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fa6a00c6 10-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

Patch by Andrej Spielmann (GSOC):
* Integrate the subpixel rendering with the existing drawing backend and
the font rendering.
* The font cache has got an additional rendering type for extracting and
caching glyph bitmaps that store subpixel coverage values.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26361 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c9d2046f 04-Aug-2007 Stephan Aßmus <superstippi@gmx.de>

* after my last changes to font rendering, it was about 15% slower than
before (although there should be much less lock contention)
* with this change, there is quite a bit of cleanup, text drawing is now
about 20% faster than before the original changes to font caching,
mostly due to turning off the kerning feature, which at the moment
gives absolutely no benefit. The correct way of doing it might be to
use kerning depending on the provided glyph spacing mode
* removed fPenLocation from Painter, the usage should be more correct now,
since it is now consistently applied before the coordinate transformation
from view to screen (also for DrawShape() now, before any view scaling
and origin offset)
* Painter no longer has it's own instance of a ServerFont, instead it uses
its AGGTextRenderer instance, which was per Painter again after the
last change, and not global anymore, made _UpdateFont() useless
* When using GlyphLayoutEngine, it supports a second pass with the same
FontCacheEntry through the introduction of a FontCacheReference. This
speeds up DrawString a little, since it needs to calculate the bounding
box for the string, and then draw the string in a second pass. This is
now done with only one FontCacheEntry lookup
* I also tried to optimize the on-the-fly conversion of UTF8->CharCode away,
since it was done four times per DrawString, but surprisingly, it proofed
to be a slight slowdown.
* introduced a shortcut in DrawingEngine::DrawString() which avoids
calculating the bounding box, we are now a tiny bit faster to figure
out that we don't need to draw any string than Dano

In the test environment (drawing to offscreen bitmap and blitting to
screen eventually), text rendering is now about 3.7 times _faster_ than Dano
text rendering (directly to screen), for untransformed text. Unfortunately
I cannot test on the same machine in accelerant using version of the test
environment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21822 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 25a70616 02-Aug-2007 Stephan Aßmus <superstippi@gmx.de>

* moved AGGTextRenderer alongside it's pal, Painter, it felt lonely,
removed font_support folder
* ServerApp can use ServerFont::StringWidth() directly again
* more ServerFont functions implemented via GlyphLayoutEngine and
custom consumer
* extended GlyphCache data structure to hole the left/right insets
of the glyph shape between its advance width, took it from the earlier
ServerFont implementation, have not tested if that gives same result
as R5
* TODO: implement GetGylphShapes via GlyphCache, although it might not
look as clean as it does now


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21805 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 91233f88a3b4dc392389fad1626c56ed0b3812a0 26-Feb-2014 Stephan Aßmus <superstippi@gmx.de>

Font: Work on support for spacing modes.

* Change default spacing to B_BITMAP_SPACING. The BeBook does not document
what the default spacing is, and I have no BeOS install handy to check.
However, I believe that B_BITMAP_SPACING is what should be the default,
since it gives the best visible result for the common use-case.
In terms of implementation, there is no change, since spacing was ignored
until now and the behavior was that of B_BITMAP_SPACING. This change could
however break BeOS apps which assume B_CHAR_SPACING is the default and don't
set it on new when they need it. Sample code in the BeBook however shows
setting B_CHAR_SPACING on a newly created BFont.
* Implement B_STRING_SPACING to do something sensible. The BeBook documentation
is completely vague in what it is actually supposed to do. Given the
possibilities of FreeType, I am implementing it to enable the use of
kerning. Kerning optimizes the spacing between two glyphs, for example, it
would decrease the spacing between "T" and "e" in the string "Test" for
our default font. Untested.


# b4671bebcf6244601660d4b89388b5eb9f91f921 06-Feb-2014 Stephan Aßmus <superstippi@gmx.de>

Regard Painter's transformation when rendering text.


# a2f075eb427e1b5d41d094f4a43a07c0417b8fa0 28-Jan-2014 Stephan Aßmus <superstippi@gmx.de>

app_server: Support alpha masks for text rendering...

... both vector and bitmap based. Sub-pixel text rendering not yet handled,
I think the scanline is used differently in this case, in that three times the
horizontal resolution is used, while the alpha map doesn't match this
increase.


# 77e5acc0d9d737051591e663ccf3376a32bfcf84 15-Mar-2010 Stephan Aßmus <superstippi@gmx.de>

* Extended the BView drawing API by a DrawString() version that takes an array
of locations, one for each glyph.
* Added a test for the new functionality.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35865 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ff4aa6dc0363eabda66d032aa66cbfd1aae3d9c9 09-Apr-2009 Stephan Aßmus <superstippi@gmx.de>

Style cleanup


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30065 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a4a780dbed86bc0f9a178899b49e3fece54657bf 19-Jan-2009 Stephan Aßmus <superstippi@gmx.de>

Removed left over.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28969 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 59e13a3f06eedbc797f797da71c6810634b22cd4 03-Aug-2008 Stephan Aßmus <superstippi@gmx.de>

Patch by Andrej Spielmann (GSoC):
* Simplified the subpixel related methods for the AGG "pixel format" template
interface, the ones for the solid cover simply pass through the existing
methods, so only one subpixel blending function is left which does the actual
work (this removes a lot of the previously added code)
* Implemented a new rasterizer based on the original AGG rasterizer which
implements subpixel anti-aliasing for any generic AGG vector pipelines. It
is now optionally used in Painter and AGGTextRenderer (for vector fonts, ie
rotated, sheared or big enough fonts) depending on the global subpixel
setting.
* Put all subpixel variables into the new GlobalSubpixelSettings.h|cpp
* Simplified DesktopSettings related classes a bit and renamed previous
FontSubpixelAntialiasing to just SubpixelAntialiasing.
* The private libbe functions for subpixel related settings moved from Font.cpp
to InterfaceDefs.cpp where other such functions live. They are not related
to fonts only anymore.
* Removed the subpixel related settings again from the Fonts preflet and added
them to the Appearance preflet instead.

All of the above implements subpixel anti-aliasing on a global scale, which
to my knowledge no other OS is doing at the moment. Any vector rendering
can optionally use subpixel anti-aliasing in Haiku now. The bitmap cached fonts
are still affected by the Freetype complile time #define to enable the patented
subpixel rasterization (three times wide glyphs). Vector fonts and shapes are
not affected though at the moment.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26755 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fa6a00c628f07c0310bbc97db6e69aca68461b82 10-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

Patch by Andrej Spielmann (GSOC):
* Integrate the subpixel rendering with the existing drawing backend and
the font rendering.
* The font cache has got an additional rendering type for extracting and
caching glyph bitmaps that store subpixel coverage values.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26361 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c9d2046fe5b12fee15b6c24960d29fd581a81cef 04-Aug-2007 Stephan Aßmus <superstippi@gmx.de>

* after my last changes to font rendering, it was about 15% slower than
before (although there should be much less lock contention)
* with this change, there is quite a bit of cleanup, text drawing is now
about 20% faster than before the original changes to font caching,
mostly due to turning off the kerning feature, which at the moment
gives absolutely no benefit. The correct way of doing it might be to
use kerning depending on the provided glyph spacing mode
* removed fPenLocation from Painter, the usage should be more correct now,
since it is now consistently applied before the coordinate transformation
from view to screen (also for DrawShape() now, before any view scaling
and origin offset)
* Painter no longer has it's own instance of a ServerFont, instead it uses
its AGGTextRenderer instance, which was per Painter again after the
last change, and not global anymore, made _UpdateFont() useless
* When using GlyphLayoutEngine, it supports a second pass with the same
FontCacheEntry through the introduction of a FontCacheReference. This
speeds up DrawString a little, since it needs to calculate the bounding
box for the string, and then draw the string in a second pass. This is
now done with only one FontCacheEntry lookup
* I also tried to optimize the on-the-fly conversion of UTF8->CharCode away,
since it was done four times per DrawString, but surprisingly, it proofed
to be a slight slowdown.
* introduced a shortcut in DrawingEngine::DrawString() which avoids
calculating the bounding box, we are now a tiny bit faster to figure
out that we don't need to draw any string than Dano

In the test environment (drawing to offscreen bitmap and blitting to
screen eventually), text rendering is now about 3.7 times _faster_ than Dano
text rendering (directly to screen), for untransformed text. Unfortunately
I cannot test on the same machine in accelerant using version of the test
environment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21822 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 25a706165200f555d65fba7648a0092a64c018af 02-Aug-2007 Stephan Aßmus <superstippi@gmx.de>

* moved AGGTextRenderer alongside it's pal, Painter, it felt lonely,
removed font_support folder
* ServerApp can use ServerFont::StringWidth() directly again
* more ServerFont functions implemented via GlyphLayoutEngine and
custom consumer
* extended GlyphCache data structure to hole the left/right insets
of the glyph shape between its advance width, took it from the earlier
ServerFont implementation, have not tested if that gives same result
as R5
* TODO: implement GetGylphShapes via GlyphCache, although it might not
look as clean as it does now


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21805 a95241bf-73f2-0310-859d-f6bbb57e9c96