Font handling a little clunky and not thread-safe?

[Vinnie-4]

I'm using the freetype engine to render text in my app. I redraw the interface very often, so pixels/second throughput is important to me.

Has anyone else noticed that the font API is a bit clunky? There is the idea of the 'current' font which breaks thread safety. It seems fonts are not as well developed as the rest.

The drawing is also a tad slow. I had to turn off kerning because it was consuming a lot of time, most of it in the Freetype engine. Anyone else notice this?

Can anyone share techniques or patches for improving the font handling? Myself, I have mostly rewritten agg_font_freetype and agg_font_cache_manager. The design of the cache was incompatible with multithreading. I made the cached font, and face objects independent, so they can be constructed without an associated manager or cache.

The agg implementation just throws away fonts when a new instance is requested and the cache is full (currently set to a default of 32). I implemented my own wrappers on agg for things like reference counting, and knowing when a font is safe to purge, so it was necessary to do away with the agg management code. Has anyone else done the same thing or noticed these deficiencies?

At the highest level of my application I threw in some OpenMP code to redraw areas that require repainting in parallel. As soon as I made redrawing run in parallel, I had all sorts of issues with fonts and agg. Most of them because freetype itself is not thread-safe (it has a notion of 'current' font). Agg itself didn't have any issue, I just created separate instances of the scanline object, renderer, etc... for each thread. Anyone else notice these problems? What are some common solutions? I had to add some mutexes in my own code to prevent two threads from clashing. For example, two threads trying to create a cached glyph at the same time. It was unfortunate, a fair bit of blocking/contention showed up in the resulting profiles.

What are some of your experiences with the text / font handling in agg?


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

[Stephan Assmus]

On 2009-08-05 at 22:15:38 [+0200], Vinnie <thevinn@...> wrote:

>
> I'm using the freetype engine to render text in my app. I redraw the
> interface very often, so pixels/second throughput is important to me.
>
> Has anyone else noticed that the font API is a bit clunky? There is the
> idea of the 'current' font which breaks thread safety. It seems fonts are
> not as well developed as the rest.
>
> The drawing is also a tad slow. I had to turn off kerning because it was
> consuming a lot of time, most of it in the Freetype engine. Anyone else
> notice this?
>
> Can anyone share techniques or patches for improving the font handling?
> Myself, I have mostly rewritten agg_font_freetype and
> agg_font_cache_manager. The design of the cache was incompatible with
> multithreading. I made the cached font, and face objects independent, so
> they can be constructed without an associated manager or cache.
>
> The agg implementation just throws away fonts when a new instance is
> requested and the cache is full (currently set to a default of 32). I
> implemented my own wrappers on agg for things like reference counting,
> and knowing when a font is safe to purge, so it was necessary to do away
> with the agg management code. Has anyone else done the same thing or
> noticed these deficiencies?

Yes, here. I think the font stuff in AGG is really more of an example. I
don't mean how it connects to AGG, but certainly the caching. As you
already found out, Freetype itself does not support using the same
FT_Library handle from more than one thread without external locking. So
anytime you pass by the cache and need to extract glyphs via Freetype, you
need to serialize the access.

> At the highest level of my application I threw in some OpenMP code to
> redraw areas that require repainting in parallel. As soon as I made
> redrawing run in parallel, I had all sorts of issues with fonts and agg.
> Most of them because freetype itself is not thread-safe (it has a notion
> of 'current' font). Agg itself didn't have any issue, I just created
> separate instances of the scanline object, renderer, etc... for each
> thread. Anyone else notice these problems? What are some common
> solutions? I had to add some mutexes in my own code to prevent two
> threads from clashing. For example, two threads trying to create a cached
> glyph at the same time. It was unfortunate, a fair bit of
> blocking/contention showed up in the resulting profiles.
>
> What are some of your experiences with the text / font handling in agg?

I've solved this problem in the Haiku app_server. Haiku is an operating
system re-implementing the BeOS as an Open Source project. The font cache
and related classes should be fairly self-contained, so maybe it is useful
to you. If you indeed look at this and compare it to the work you already
did, and if you find something I could improve, please let me know.

<http://dev.haiku-os.org/browser/haiku/trunk/src/servers/app>

You will want to look at these classes:

FontCache
FontCacheEntry
FontEngine
GlyphLayoutEngine

The actual rendering happens in the sub-folder drawing/Painter. Each window
on the screen renders in it's own thread, while the frame buffer is
read-locked. When the clipping is changed for the windows, it happens with
a write lock.

As for the rest of what you wrote, I came up with the same solutions,
separate scanline, renderer and rasterer per thread. However, I think that
it has to be done like this is very much expected. Other than the glyph
cache locking, I don't see much reason for contention. In my solution, I am
read-locking the font cache (which has a lock per font), see if all the
glyphs are already cached, if not, switch to write lock, insert the glyphs
as needed. This means that there is only contention for a very short time
in the beginning, until pretty much all the glyphs are cached. Then the
read-locking is sufficient, and the only overhead is the iteration to check
if all glyphs of the current string are already cached.

Best regards,
-Stephan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

[Jim Crafton]

Thanks for following up on this Stephan, that's actually very
interesting! Are you using Haiku (I still think of it as BeOS!) as
your full time OS? I remember loving BeOS back in '97/'98.

Cheers

Jim

On Wed, Aug 5, 2009 at 5:45 PM, Stephan Assmus<superstippi@...> wrote:

>
> On 2009-08-05 at 22:15:38 [+0200], Vinnie <thevinn@...> wrote:
>>
>> I'm using the freetype engine to render text in my app. I redraw the
>> interface very often, so pixels/second throughput is important to me.
>>
>> Has anyone else noticed that the font API is a bit clunky? There is the
>> idea of the 'current' font which breaks thread safety. It seems fonts are
>> not as well developed as the rest.
>>
>> The drawing is also a tad slow. I had to turn off kerning because it was
>> consuming a lot of time, most of it in the Freetype engine. Anyone else
>> notice this?
>>
>> Can anyone share techniques or patches for improving the font handling?
>> Myself, I have mostly rewritten agg_font_freetype and
>> agg_font_cache_manager. The design of the cache was incompatible with
>> multithreading. I made the cached font, and face objects independent, so
>> they can be constructed without an associated manager or cache.
>>
>> The agg implementation just throws away fonts when a new instance is
>> requested and the cache is full (currently set to a default of 32). I
>> implemented my own wrappers on agg for things like reference counting,
>> and knowing when a font is safe to purge, so it was necessary to do away
>> with the agg management code. Has anyone else done the same thing or
>> noticed these deficiencies?
>
> Yes, here. I think the font stuff in AGG is really more of an example. I
> don't mean how it connects to AGG, but certainly the caching. As you
> already found out, Freetype itself does not support using the same
> FT_Library handle from more than one thread without external locking. So
> anytime you pass by the cache and need to extract glyphs via Freetype, you
> need to serialize the access.
>
>> At the highest level of my application I threw in some OpenMP code to
>> redraw areas that require repainting in parallel. As soon as I made
>> redrawing run in parallel, I had all sorts of issues with fonts and agg.
>> Most of them because freetype itself is not thread-safe (it has a notion
>> of 'current' font). Agg itself didn't have any issue, I just created
>> separate instances of the scanline object, renderer, etc... for each
>> thread. Anyone else notice these problems? What are some common
>> solutions? I had to add some mutexes in my own code to prevent two
>> threads from clashing. For example, two threads trying to create a cached
>> glyph at the same time. It was unfortunate, a fair bit of
>> blocking/contention showed up in the resulting profiles.
>>
>> What are some of your experiences with the text / font handling in agg?
>
> I've solved this problem in the Haiku app_server. Haiku is an operating
> system re-implementing the BeOS as an Open Source project. The font cache
> and related classes should be fairly self-contained, so maybe it is useful
> to you. If you indeed look at this and compare it to the work you already
> did, and if you find something I could improve, please let me know.
>
> <http://dev.haiku-os.org/browser/haiku/trunk/src/servers/app>
>
> You will want to look at these classes:
>
> FontCache
> FontCacheEntry
> FontEngine
> GlyphLayoutEngine
>
> The actual rendering happens in the sub-folder drawing/Painter. Each window
> on the screen renders in it's own thread, while the frame buffer is
> read-locked. When the clipping is changed for the windows, it happens with
> a write lock.
>
> As for the rest of what you wrote, I came up with the same solutions,
> separate scanline, renderer and rasterer per thread. However, I think that
> it has to be done like this is very much expected. Other than the glyph
> cache locking, I don't see much reason for contention. In my solution, I am
> read-locking the font cache (which has a lock per font), see if all the
> glyphs are already cached, if not, switch to write lock, insert the glyphs
> as needed. This means that there is only contention for a very short time
> in the beginning, until pretty much all the glyphs are cached. Then the
> read-locking is sufficient, and the only overhead is the iteration to check
> if all glyphs of the current string are already cached.
>
> Best regards,
> -Stephan
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

[Stephan Assmus]

On 2009-08-06 at 01:37:53 [+0200], Jim Crafton <jim.crafton@...>
wrote:
> Thanks for following up on this Stephan, that's actually very
> interesting! Are you using Haiku (I still think of it as BeOS!) as your
> full time OS? I remember loving BeOS back in '97/'98.

Forgive me for replying on the list, everyone, but with proud and delight I
have to say that I am using Haiku as my full-time OS. :-D

Although Haiku is much faster in many respects than BeOS was, Linux is
still faster at compiling a Haiku image, almost 3 times. Some of it is due
to the fact that I am running a lot of kernel tracing, so some useful
information is there, when the system does crash. So when I upgrade my
system to the newest revision, I use my Linux host to compile it. But
otherwise, I am using Haiku full-time for application and Haiku
development. For my next job project, I will have to use Linux again, since
it's Qt-based and we do not yet have a Qt port for Haiku (not even sure it
would be a good thing). But for everything else, using Haiku just feels
much better to me. All the apps launch instantly... elegant user
interface... just like good old BeOS times, only without a lot of the
quirks and modernized.

Best regards,
-Stephan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

[Jim Barry-2]

Vinnie wrote:
> Can anyone share techniques or patches for improving the font
> handling? Myself, I have mostly rewritten agg_font_freetype and
> agg_font_cache_manager. The design of the cache was incompatible with
> multithreading. I made the cached font, and face objects independent,
> so they can be constructed without an associated manager or cache.    

Yes, same here. I had to rewrite the font stuff pretty much from scratch. I'm only interested in vector fonts so I was able to simplify the code quite a bit, and also to make some optimisations. For example, I simply store each glyph outline in a path_storage object, and I convert the curves to straight-line segments once at load time, instead of doing it every time a glyph is rendered. Fortunately my GUI is all in one thread, so I don't have to worry about thread safety :)

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general