Hi John, libart does not do anything 'expensive' before the gfx_render_png step ... you can verify this by creating eps output ... this is about 8 times faster than png output ...
so what you need to implement is gfx_render_pnggd cheers tobi > 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 > -- ______ __ _ /_ __/_ / / (_) 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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-developers WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
