[Freetype] Re: Your rasterizer (ftgrays.c)

[David Turner]

Hi Martin,

> 
> Dear David,
> 
> [...]
>
> How does your rasterizer compare to libart's? I want to draw several shapes
> on my bitmap (one on top of another) and add alpha to each shape. Should I
> even try to incorporate the code in ftgrays.c? It seems that if I modify
> grays_render_span I should be able to do all this (including rendering to
> 16,24,32 bit bitmaps and rendering different color shapes I hope). Is it
> suitable for rendering large shapes?

Both libraries / toolkits will produce the same anti-aliased shape,
given
the same input paths. However, there are important differences in their
design and use:

for "ftgrays.c":

  - it can be compiled standalone, without the rest of FreeType
    (simply take "ftimage.h", "ftgrays.h" and "ftgrays.c")

  - it doesn't use floating points (it's important for me because
    I use it for a graphics lib that runs on the iPaq, among other
    things).

  - it handles bezier curves gracefully (i.e. doesn't previously
    decompose them into segments).

  - it needs a "work buffer" that can be from 4 Kb to wathever
    (16 Kb is recommended). It automatically decomposes the
    work if an outline is too complex or too large to be
    rendered in one pass.

    This also means that you'll need to provide a large
    "work buffer" to render large shapes at top speed
    (it was optimised to render small and complex shapes like
     glyphs at very high speed)

  - the "work buffer" must be provided by the application, is
    only used during scan-conversion (so you can share it with
    something else if you need to). However, the code doesn't
    perform any memory allocation/release

  - the input points are expressed in 1/64th of pixels with
    32 bits, you're limited to the range [-2^26 .. 2^26-1]
    pixels if you really need that much pixels..

for LibArt:

  - I don't know if you can separate the anti-aliased renderer
    from the rest of the library, but I assume that this is
    possible with minimal work, knowing Raph's code style.

  - it uses doubles exclusively

  - it doesn't need a work buffer, but will allocate a small
    buffer used during shape parsing.

  - it doesn't know about bezier curves !! only line segments.
    you basically need to convert a path into a "sorted vector
    path" made exclusively of line segments. Given that each
    point is made of two doubles (2*8 == 16 bytes each), this
    means that complex shapes, like glyphs, can take a lot of
    memory.


Of course, it's possible to hack "ftgrays" to not use a "work
buffer", and to hack LibArt to understand bezier curves naturally,
but both tasks are non trivial, and absent from the libraries
respective authors priority lists :-)

> Do you have any sample code that would help me understand how it works? Do
> you have any suggestions as to how I would go about implementing a function
> like this:
> DrawPolygon(rect *r, int n, char *buf, int w, int h) where r is an array of
> n points (x,y) which form a closed polygon and buf is a pointer to a 24bit
> bitmap of width w and height h? Would this be simple or very hard to
> implement?
>

I don't have an example handy, but basically, you'd need to:

  - convert your polygon to a FT_Outline (see FT_Outline_New,
    FT_Outline_Done)

  - call FT_Outline_Render, by taking care of providing your
    own span callback to write to your own bitmap

Hope this helps,

- David