Commit Graph

3 Commits

Author SHA1 Message Date
Stephan Aßmus
c9d2046fe5 * 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
2007-08-04 11:37:16 +00:00
Stephan Aßmus
25a7061652 * 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
2007-08-03 01:11:27 +00:00
Stephan Aßmus
2222864eed * complete overhaul of the font/glyph caching
* the previous AGG implementation is superfluous
* the new implementation is based on that one, but in a way that allows
  read/write locking to the list of cache entries (fonts) as well as
  read/write locking to the cached glyphs per individual font cache entry
* new GlyphLayoutEngine.h, which is to be the central place for layouting
  glyphs along the baseline.
  It handles the locking for getting the font cache entries.
  It works by giving it a template class GlyphConsumer which does the
  actual work.
* changed AGGTextRenderer to use the new font cache
* changed ServerFont::StringWidth(), and the bounding box stuff to use it
* changed DrawingEngine, it doesn't need the global font lock anymore
* our BFont thought that GetBoundingBoxesAsGlyphs and GetBoundingBoxesAsString
  is the same, which of course it isn't, hence the two separate functions...
  AsGlyphs just gets the bounding box of each glyph in a string, not treating
  the string as an actual word
  AsString adds the offset of the glyph in the word to the bounding box
* changed ServerProtocol.h accordingly for the different bounding box meaning


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21797 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-08-02 19:10:38 +00:00