[rrd-developers] Re: GD in rrdtool 1.2

[John]

On Sun, May 08, 2005 at 17:00:48 +0200, Tobias Oetiker wrote:
> 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 ...

What I wanted to do was get rid of libart as a _required_ backend,
but perhaps this is unnecessary. Maybe accepting/requiring libart as a
backend is a good thing?

I was hoping reducing the backend use would speed things up, but since
gfx_add_point() is often used, there's no getting around keeping
everything in abstract form until the rendering is performed. (In
either case, art_vpath_add_point() seems pretty light-weight to me.)

Is requiring libart as good thing? If not, should we build a private
substitute (used just to describe all the nodes: ART_LINETO etc) or 
should gfx_new_*() code simply call gfx_new_*_[renderer](), which
might allow a specific renderer to do something more efficient?

If libart is to be kept, I'll try to write some code to convert the
libart structure into a GD image at the time of rendering. (I'm not
sure this will save any running time though, but at least we'll get
non anti-aliased output ;))

> this is all a bit difficult to decide without seeing code :-)
To be posted when I figure out the best way of doing things ;)

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