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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-developers WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
