Re: Gnuplot module: Patching of Gnuplot binary still needed?

[Mojca Miklavec <mojca.miklavec.lists@gmail.com>]

On Mon, Nov 22, 2010 at 20:15, Florian Wobbe wrote:

> Especially for line drawings it would be beneficial not to place every single point. Instead consecutive points should be skipped if they are close to each other (with regard to plot units) - it makes no sense to include points which you won't see anyway. This could be done by defining a grid with a certain (user defined) resolution and rounding the coordinates (plot units) of a line point to the nearest grid node. All consecutive line points falling on the same grid node should not be passed on to terminal drivers. The psxy utility of GMT (http://gmt.soest.hawaii.edu/) does this for instance. I am not aware of such a functionality within gnuplot but it would be a nice feature.

But this is an issue of Gnuplot, not something that a terminal writer
is supposed to think of.

One thing that I did implement in ConTeXt was that if I get instructions
   move_to(10,3)
   line_to(11,8)
   line_to(11,8)
   line_to(11,9)
then one line_to(11,8) will be ignored (resolution is hard-coded in
the terminal, but you could draw a smaller plot and then magnify it
which would seemingly decrease resolution). But in most cases that
wouldn't really help.

About the timing difference between "set term context" and "set term
lua context": it is quite possible that metapost library is much
faster than TikZ which uses TeX-based macros. TeX might be slower in
calculations than metapost (which uses C for low level calculations)
and TikZ is not optimized for drawing ten-thousand segments. And Hans
really tried hard to optimize the code. Processing the output with
ConTeXt is also at least ten times slower that outputting straight to
PS or PDF and if you try ConTeXt MKII it is about two times slower
than MKIV.

You probably didn't have a chance to try the first implementations of
ConTeXt terminal for gnuplot. It needed 10 minutes for 13 ordinary
plots and it ran out of memory if I tried to plot 14 of them!!! (The
reason was the usage of "btex text etex" constructs which lead to
ConTeXt runs inside metapost runs inside ConTeXt runs, all doubled,
maybe the labels were compile even four times, usually with a separate
instance of ConTeXt for each plot.) Now compare that speed difference
and the enormous optimization that Hans implemented back in 2006 ...

The slow speed of TikZ is not something that you could do much about.
There might be some tiny room for optimization in
gnuplot-lua-tikz-common.tex, but hardly any. LuaTeX-based TikZ could
be reimplemented and that would bring most benefits, but since Till
almost-quit the project and since it works out-of-the-box with pdfTeX
macros it is highly unlikely to happen.

But yes, it would be nice if also ConTeXt terminal would be included.
It still doesn't support raw images, but most other features are
present.

Mojca
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________