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