[rrd-developers] Re: GD in rrdtool 1.2

[Tobias Oetiker]

Hi John,

the idea of rrd_gfx was to allow for the production of different
output format ... supporting several renderers for the same format
was not the initial idea, but if you manage to integrate libgd
sensibly this is find ...

from the interface point of view I would prefer if the gd renderer
was integrated into the output format switch ... so instead of

PNG we would get gdPNG ...

as for the 'heavy' reorganisation, I would thing that you
additional render code should be integrated like the one for
svg/pdf/eps ...

since we have more renderers now, it might be sensible to split out
the library specific code into external c files ...

this is all a bit difficult to decide without seeing code :-)


cheers
tobi
>
> In my continuing mission to abolish mandatory anti-aliasing I had a
> look at reimplementing support for GD in rrdtool.
>
> I did a quick-and-dirty implementation (supporting only basic
> polygons and lines, and text) and it seems to work OK. It does require
> some heavy reorginazation of the code though, so I'd like to elicit
> some comments/opinions before I do a clean implementation.
>
> What I had in mind was the following short step-by-step program:
>
> A, Implement support for multiple renderers
>   1, Move all libart, perhaps also freetype, references out of
>      rrd_gfx.[ch] to rrd_gfx_libart.[ch].
>   2, Add --renderer={libart,gd,...}, where the available options
>      depend on what configure finds. (Should no renderers be a
> 	 configure-error?)
>   3, Change relevant gfx_* functions to call gfx_*_[renderer], if
>      renderer supports the function. (Or should function pointers
> 	 be used for speed (the gain ought to be negligible)?)
>
> B, Implement rrd_gfx_gd.c
>
> C, Enjoy bitmapped or anti-aliased output :)
>
> Perhaps there should be a --renderer-options=flag1,flag2. For example,
> gd supports but doesn't require freetype, --renderer-options=[no]freetype
> would [de]activate it. It also supports anti-aliasing, although I
> guess libart should be used if AA is wanted.
>
> Since step A requires some heavy reorganization, and some minor
> rewrites to make gfx_node_t/etc independent of libart, I'd prefer to
> have it implemented successfully (that is, working just as it is now)
> before starting on step B.
>
>
> Would anyone be interested in this? If I'm the only one, I'll just
> link rrdtool against a patched libart with no anti-aliasing. :)
>
> --
> Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
> Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
> Archive     http://lists.ee.ethz.ch/rrd-developers
> WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi
>

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker @ ISG.EE, ETL F24.2, ETH, CH-8092 Zurich
 / // _ \/ _ \/ /  System Manager, Time Lord, Coder, Designer, Coach
/_/ \.__/_.__/_/   http://people.ee.ethz.ch/oetiker +41(0)44-632-5286

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-developers
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi