Agg train leaving the station, all aboard!

[Vinnie-4]

> 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 is a great idea, in my excitement to admire the results of accelerated drawing with multiple threads, I overlooked using read/write locks instead of straight mutexes. This will certainly benefit me because currently, access to a cached glyph is serialized (yuck).

Having one lock per font is an interesting idea but in my application I am only using one font so that is unfortunately not going to help. Thinking about multiple locks though, this doesn't solve the problem that Freetype does not have a thread-safe interface. Perhaps it would be possible to modify Freetype so that you could have multiple 'flyweight' instances of the library handle, and have them all point back to the underlying font data in some sort of singleton. This way, the font data only needs to get loaded once, but multiple lightweight library instances can each maintain their notion of a 'current' face for the purpose of updating the ascent, descent, and every other piece of font releated data except for the outlines themselves.

I am loath to undertake such modifications, however, if they are going to put out a new library that I would have to re-integrate.

> ...the only overhead is the iteration to check
> if all glyphs of the current string are already cached.

I haven't done much in terms of optimizing this process, so currently I am just calling glyph() for each character and then drawing, within the context of a lock. Your approach sounds like an improvement, i.e. take the read lock, and do a first pass through checking to see if any glyphs need to be cached (and taking the write lock if that is the case). Although I am not 100% sure this is an improvement over just doing it one glyph at a time. Thoughts?

>
> Best regards,
> -Stephan
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 5 Aug 2009 22:02:08 +0000
> From: Petr Kobal??ek <kobalicek.petr@...>
> Subject: Re: [AGG] Found the rgba blending code!
> To: Anti-Grain Geometry <vector-agg-general@...>
> Message-ID:
>     <8b9203090908051502k6fb29e40ode22f8e20570f7e4@...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Vinnie,
>

> SSE2 code I wrote (currently there is only SRC, DST,
> SRC_OVER and
> DST_OVER) is here:
>      http://code.google.com/p/fog/source/browse/trunk/Fog/Fog/Graphics/Raster/Raster_SSE2_composite.cpp.h
>      (currently it's 10.000 lines of
> SSE2 code, ready to port to
> antigrain :-D ?)

That looks extremely promising! But there are some unrelated types (Closure?). I was hoping for drop-in replacements for blender_rgb and pixfmt_alpha_blend_rgb (and I won't be too disappointed if the silver platter is excluded).

Actually, these are the agg routines that are taking up most of the time:

<agg_rasterizer_cells.h>
template<class Cell>
void rasterizer_cells_aa<Cell>::line(int x1, int y1, int x2, int y2)

void pixfmt_alpha_blend_rgb::blend_solid_hspan(int x, int y, unsigned len, const color_type& c, const int8u* covers);

I'm not seeing a FOG replacement for blend_solid_hspan am I looking in the wrong place?

Thanks to everyone for their valuable comments!






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

[Petr Kobalíček]

Hi Vinnie,

2009/8/6 Vinnie <thevinn@...>:

>
>> 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 is a great idea, in my excitement to admire the results of accelerated drawing with multiple threads, I overlooked using read/write locks instead of straight mutexes. This will certainly benefit me because currently, access to a cached glyph is serialized (yuck).
>
> Having one lock per font is an interesting idea but in my application I am only using one font so that is unfortunately not going to help. Thinking about multiple locks though, this doesn't solve the problem that Freetype does not have a thread-safe interface. Perhaps it would be possible to modify Freetype so that you could have multiple 'flyweight' instances of the library handle, and have them all point back to the underlying font data in some sort of singleton. This way, the font data only needs to get loaded once, but multiple lightweight library instances can each maintain their notion of a 'current' face for the purpose of updating the ascent, descent, and every other piece of font releated data except for the outlines themselves.
>
> I am loath to undertake such modifications, however, if they are going to put out a new library that I would have to re-integrate.
>
>> ...the only overhead is the iteration to check
>> if all glyphs of the current string are already cached.
>
> I haven't done much in terms of optimizing this process, so currently I am just calling glyph() for each character and then drawing, within the context of a lock. Your approach sounds like an improvement, i.e. take the read lock, and do a first pass through checking to see if any glyphs need to be cached (and taking the write lock if that is the case). Although I am not 100% sure this is an improvement over just doing it one glyph at a time. Thoughts?
>
>>
>> Best regards,
>> -Stephan
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 5 Aug 2009 22:02:08 +0000
>> From: Petr Kobal??ek <kobalicek.petr@...>
>> Subject: Re: [AGG] Found the rgba blending code!
>> To: Anti-Grain Geometry <vector-agg-general@...>
>> Message-ID:
>>     <8b9203090908051502k6fb29e40ode22f8e20570f7e4@...>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi Vinnie,
>>
>
>> SSE2 code I wrote (currently there is only SRC, DST,
>> SRC_OVER and
>> DST_OVER) is here:
>>      http://code.google.com/p/fog/source/browse/trunk/Fog/Fog/Graphics/Raster/Raster_SSE2_composite.cpp.h
>>      (currently it's 10.000 lines of
>> SSE2 code, ready to port to
>> antigrain :-D ?)
>
> That looks extremely promising! But there are some unrelated types (Closure?). I was hoping for drop-in replacements for blender_rgb and pixfmt_alpha_blend_rgb (and I won't be too disappointed if the silver platter is excluded).

the Closure is currently information that is used if direct blitter is
not supported. Closure contains informations about all blitters for
the compositing operator you are currently using. For example if you
want to blit 24-bit RGB image to PRGB32 destination and this blitter
is not directly supported by Fog::Raster, then instead of NULL
pointer, the adaptor will be executed. Adaptor is able to convert
pixel formats for both, source and destination to supported formats
for implemented blitters and run them instead of crash.

Design of the Fog library allows mixing pixel formats, and is logical,
that I can't write all code for all possible combinations (I
calculated this and got result of 4000 blitters in SSE2, other
optimizations as well). So I'm implementing only most useful blitters.

If you want use the code and you don't need adaptors (converters
between pixel formats) you can ignore all Closures and just use the
code:)
.

>
> Actually, these are the agg routines that are taking up most of the time:
>
> <agg_rasterizer_cells.h>
> template<class Cell>
> void rasterizer_cells_aa<Cell>::line(int x1, int y1, int x2, int y2)
>
> void pixfmt_alpha_blend_rgb::blend_solid_hspan(int x, int y, unsigned len, const color_type& c, const int8u* covers);
>
> I'm not seeing a FOG replacement for blend_solid_hspan am I looking in the wrong place?

No, it's right place and functions are here :)

- raster_prgb32_span_solid_srcover_sse2 - PRGB32 destination and solid
source color.
- raster_prgb32_span_solid_a8_srcover_sse2 - PRGB32 destination and
solid source color with A8 (8-bit) mask.
- raster_prgb32_span_solid_a8_const_srcover_sse2 - PRGB32 destination
and solid source color with A8 (8-bit) mask that is constant for each
pixel.

Convention is:
- 'raster' + '_' + 'destination pixel format' + '_' + 'span (solid) or
composite (blitter)' + '_' + ['mask' + '_'] + 'operator' + '_' +
'optimization'

> Thanks to everyone for their valuable comments!
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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]

Hi,

On 2009-08-06 at 13:23:19 [+0200], Vinnie <thevinn@...> wrote:
> I haven't done much in terms of optimizing this process, so currently I
> am just calling glyph() for each character and then drawing, within the
> context of a lock. Your approach sounds like an improvement, i.e. take
> the read lock, and do a first pass through checking to see if any glyphs
> need to be cached (and taking the write lock if that is the case).
> Although I am not 100% sure this is an improvement over just doing it one
> glyph at a time. Thoughts?

Locking has some overhead, especially if it's a read/write lock. So you
should definitely not do it one glyph at a time. In my setup, where I am
dealing with one drawing thread per window on screen, I have potentially a
lot of threads accessing certain fonts (like the system font), for example
when a window is moved on screen and all the windows beneath it need to
redraw (Haiku doesn't yet have a 3D accelerated desktop, where every window
is buffered in a texture). What helps is that strings are usually quite
short, and never multi-line. Also, applications will most likely have
figured out the string width, so they can center or right-align a label.
That means that in the rare case that a thread has to write lock, it will
most likely not keep the lock for long, since chances are it's measuring
the string width, not actually drawing.

It is certainly possible that this can still be optimized a lot, since the
pre-flight on the string is mostly useless since very early in the game,
but I don't know how else to do it, if there is still the chance that a
write lock is needed. One option would be to simply cache all the glyphs
upfront, even if noone needs them yet. But our fonts support a lot of
glyphs. It could be done for all one-byte UTF8 characters for example, so
that for such strings, the check is never done. But in any case, I can tell
you that my approach definitely works very well in Haiku as it is.

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