New Rasterizer available..

[David Turner]

Hi Just,

> >1)  Has anyone done this before?
> 
> I've been using the FT rasterizer as a standalone unit in an experimental
> setup. It works really well.
> 
Thanks, I'd like to inform you that apparently, I've found that ftraster.c
produces some unexpected artifacts at small pixel sizes. These are really
hard to spot but can be rather bothering if you want the highest possible
quality..

I believe that these artifacts are a consequence of the algorithm used
in the raster, and that they will be hard to get rid of. One solution
would be to perform post-processing on the outline (sort of filtering),
but this would take time..

> However it only draws filled shapes: so if your graphics package needs
> stroked polygons/bezigons, you still need to roll your own converter.
> Still: it would be very cool for FT2 to have a stroke renderer! I've been
> meaning to look into writing a very simple one, which would only do 1-pixel
> strokes. No time...
> 
Well, I have not currently the time to do this, I hope someone comes with
one here. A path stroker isn't exactly too difficult to implement when you
don't need large stroke width..

> >2)  FreeType 1.x rendered to temporary pixmap that had to be copied
> >(with alpha compositing) to the main pixmap.  Can FreeType 2.0 rasterize
> >directly to the main canvas?  If not, can it be modified to do so?
> 
> Not at present, but David mumbled something about working on a version that
> can. No idea about the status of that. I think it's hard to modify the
> current rasterizer to do what you want.
> 

All right, I have just commited to the CVS Repository my current working
version of this new raster. Everything is in "demos/src", look at the files
"ftgrays.h" and "ftgrays.c".

I have also updated the "ftview" and "fttimer" modules in order to support
it. When in "ftview", press "g" to toggle between the "old" and "new" renderer,
and see the difference..

Note that the new code computes the _exact_ coverage of the outline on each 
pixel
grid. However, some diagonals & curves look more fuzzy than with the old 
ftraster.c
I believe this could be corrected in a near future through a gamma table or 
something
similar..

I guess that for normal graphics processing, this doesn't really matter.
And yes, the new renderer is (theorically) capable of direct composition
and doesn't need an intermediate bitmap.

See the function "grays_render_span", it is the prototype of the callback
you'll need to provide to the renderer (in a not too distant future) to
draw to any kind of surface.

Note that the code is still in beta (at least it doesn't seem to crash anymore 
:-),
the even_odd/non-zero filling rules are not properly implemented, but hey...

It will ultimately be moved to the "freetype/src/base" some day or the other..

Have fun hacking graphics with it..

- David

> Just