[SciPy-user] FW: anti-grain

[David Ascher]

eric jones wrote:

> Right.  The Kiva API is DisplayPDF and therefore vector based.  That
> won't change.  The PDF backend will definitely stay, and I would like to
> see PS/EPS and SVG backends built (thanks for the PIL backend Dave).  

The SVG backend is most of the way there, and PS/EPS will be easy -- I may get 
to them over the weekend.

PS/EPS and SVG all have the problem that Chaco wants to measure font widths to 
figure out "by itself" where to place left-aligned text.  Font width 
computations aren't available to "pure" PS/EPS/SVG/PDF.

The PDF backend works because reportlab ships with a "scary" database of glyph 
widths.  I don't particularly like that approach, since it doesn't scale well 
(if you want to use any but the standard 14 fonts, you're SOL), puts a 
significant memory burden on the app, but most of all, I think it's unnecessary 
in most cases.

It would be possible to avoid the need to ask for text width for the sake of 
drawing labels in many back-ends -- however, I realize that Chaco needs to 
figure out dimensions of things for its layout engine -- not just to draw frames 
around titles, but to figure out how big graphs are, etc.

What I'll probably do is to rip out the fontdata and string-width-computation 
code out of reportlab and make it more standalone.  With some database 
compression, it can probably be fairly lightweight.  That way any backend which 
uses the standard fonts can get font widths without having to load the fonts 
into memory -- obviously not relevant for FreeType-based backends, since they 
need the fonts to produce their output, but useful for any "delayed rendering" 
formats.
[...]

> Building a new Kiva backend is then as simple as learning how
> to blit this thing into the screen for a new toolkit.  

Yup.

> The GUI
> interaction portion of Chaco might be significantly refactored when we
> go down this road also to make porting that part of Chaco much easier
> also.  It may not even be any better to keep a OpenGL version around
> since we can blit anti-grain images into it just as easily as other
> APIs.  I guess this decision will depend on speed.

Right -- OpenGL has hardware acceleration at least on some platforms and is the 
result of hundreds of man-years of optimization and testing.  It'll be a while 
before anti-grain matches that, although anti-grain's 2-d model is a better fit 
for Kiva, and probably benefits from shortcuts which OpenGL can't afford.

> The only potential downside that I see is if anti-grain is slower at
> drawing than the GUI toolkits.  Anti-grain looked plenty fast to me in
> the demos I have looked at -- it looked just as fast as GDI+ (windows
> new path based rendering API), but we'll just have to wait and see on
> this one.  

Right -- the demos that I tried, AFAICT, only computed once -- everything else 
was presumably cached.

Regardless, having more backends is only for the good -- it helps define the API 
better, provides portability (if anti-grain isn't available when creating a png, 
use PIL instead, etc.).

If I didn't have such an allergy to C++, I'd probably have volunteered to help 
w/ the agg backend =).

--david