# Is there an advantage in using the pgf Basic Layer over tikz?

I'm working on a program to draw crystal unit cells with pgf/tikz. In the course of this project the question arose whether I should draw the constituent bonds and atoms using pgf Basic Layer commands or tikz commands. It's clear to me that some things like declaring shadings and such need to be done in pgf but I'm asking for situations where the exact same result can be achieved with Basic Layer or tikz commands. Can there be an advantage in using the more low level Basic Layer over the tikz commands in such situations or is it equivalent? Are there situations where I can/should use a pgfpicture but not a tikzpicture environment?

Edit: Since @percusse mentioned, that the answer might depend on the particular use case I will provide a small example: I plan to draw the atoms in the crystal unit cells I want to depict as circles with a spherelike shading. The following MWE contains two versions of such an "atom" which look exactly the same, one drawn solely with Basic Layer commands the other with tikz commands. For the sake of brevity I enclosed them in the same tikzpicture environment. The question would then be, if the Basic Layer version might be more easily tweakable or more compatible with PDF viewers or has any advantage at all over the tikz version? In terms of amount of code and readability the tikz version would clearly be preferable.

\documentclass{standalone}

\usepackage{tikz}

\begin{document}

\pgfdeclareradialshading{new}{\pgfqpoint{0bp}{0bp}}{%
color(0bp)=(blue);
color(6bp)=(blue!90!black);
color(20bp)=(black!75!blue);
color(30bp)=(black!85!blue)}

\begin{tikzpicture}

% tikz version
\begin{scope}
\clip (-1,0) circle (1cm);
\draw [fill=black!70] (0, 0) circle (1cm);
\begin{scope}[transform canvas={xshift=-1cm, rotate=45}]
\shade [shading=new] (0.00,0.50) ellipse (1.75 and 1.55);
\end{scope}
\node (nodename) at (-1, 0) [circle, minimum size = 2cm] {tikz};
\end{scope}

% Basic Layer version
\begin{pgfscope}
\pgfpathcircle{\pgfpoint{3cm}{0cm}}{1cm}
\pgfusepath{clip}
\begin{pgflowlevelscope}{\pgftransformshift{\pgfpoint{3cm}{0cm}}, \pgftransformrotate{45}}
\pgfpathellipse{\pgfpoint{0cm}{0.5cm}}
{\pgfpoint{1.75cm}{0cm}}
{\pgfpoint{0cm}{1.55cm}}
\pgfshadepath{new}{0}
\pgfusepath{}
\end{pgflowlevelscope}
\end{pgfscope}
{
\pgftransformshift{\pgfpoint{3cm}{0cm}}
\pgfset{minimum size=2cm}
\pgfnode{circle}{center}{pgf}{nodename}{
\pgfusepath{}}
}

\end{tikzpicture}

\end{document}


-
Front layer : not flexible but much easier. Basic layer : Tedious but much more flexible. System layer : Ridiculous but everything is possible as much as the driver allows. An apparent example is the arc drawing variations compared. –  percusse Jul 22 '13 at 13:12
@percusse In my specific case I will have to mix in some Basic Layer code anyway. So, it wouldn't be much trouble for me to write the rest in a pgfpicture compatible way. But I would prefer using some tikz code for such things like the creation of nodes and maybe canvas transformations but only if nothing speaks against it. –  Philipp Jul 22 '13 at 13:19
Not really. I just wanted to clarify what you meant by the layer usage. But still the answer depends on the use case you have in mind. Otherwise every tikz based command is mapped back into PGF commands. As far as I know there are no TikZ commands that communicates directly to the system layer. So it becomes a convenience and maintanence issue. –  percusse Jul 22 '13 at 13:56
Before tikz was invented / published, I made a very extend collection of pgf pictures for my lecture notes and other papers. Over the years, I am rewritting them step by step into tikz code. The main reason is that tikz code is much more compact, easier to understand when you look at it some years later, and, therefore, easier to maintain. So, from my experience, I would also recommend to use the front layer. –  Thomas F. Sturm Jul 22 '13 at 15:19
Since everything is mapped to the basic layer, I guess you only pay a penalty during compile time for another level of indirection, but giving the comfort of tikz code this is neglegible. Of the top of my head I do not know of cases where pgf and tikz dont mix. Maybe there is a tikz command that maps to pgf command with limits (Imagine there was no fill option for the sake of example), this would mean you would have to translate that part of your picture to pgf to fill it. However I am NOT aware of such cases. –  ted Jul 22 '13 at 16:05
show 5 more comments

## 1 Answer

A biased answer based on my own experience so please take it with a grain of salt.

Well, first of all we need to take into account that PGF is the deal. TikZ is just the PR department and an incrediibly good one. The whole idea of TikZ is very similar to TeX and LaTeX where PGF being TeX. Sometimes you have to go down to the basement and fix the boiler etc. but in general it is designed solely for the user convenience. Therefore TikZ itself is not a graphics package but as the name implies a front-end to PGF. Amazingly, almost(!) everything is converted to key-value system and that makes life very very easy which wasn't like that until even in 2005. But again as far as I know there are no direct TikZ commands that leads to the drive specific system layer. In fact it has to pass through the soft path system so I'm almost sure.

Because PGF is low-level, just by swapping the order of things or adding a simple command would make a lot of difference via PGF, however, in the straights TikZ will always win because the remaining parts should still be typed out. Arguably some things are very difficult to map to the frontend layer, as you mentioned, shadings or decorations etc. so there is a portion of PGF commands that are left out and that is what might be worth going all the way PGF. Another issue is the speed. TikZ is big. I mean really big so skipping it makes a big difference in terms of compile times. Moreover, TikZ parses the syntax by checking the letters one by one to understand what it is and that takes a lot of time the shortest words on the path stream has to pass at least four five ifnextchar switches. Instead PGF just works with macros.

Other than that, it is my personal preference to mix TikZ syntax with PGF syntax. However if you are designing a package that will use similar objects all the time (like shadings though they will mostly fail to be reused if PS or Dvi->PS route is followed), I would recommend going straight to the system level for object reusing and protocolling. They are more CS-geeky concepts and I can't do justice here. But even object oriented programming possibilities are present. I barely remember that Andrew Stacey did some work on it.

Here are a few nontrivial things, in my opinion and that I can remember right now, that are not worth attacking via Frontend Layer TikZ unless you intentionally write your own library for it;

• Clipping via node shapes: This is probably a design choice because there is no reason that I can see why it wasn't included in TikZ. Example (stolen from Tikz clip shapes with another (built in) shape );

\usetikzlibrary{shapes.callouts}

\begin{tikzpicture}
\pgfnode{cloud callout}{center}{}{nodename}{\pgfusepath{stroke,clip}}
\fill[red] (-1mm,-4mm) rectangle (2.5mm,1mm);
\end{tikzpicture}


• The arcs are way easier to use and diverse; especially \pgfpatharctoprecomputed and \pgfarcto are of great convenience.

• Ordered path and canvas transformations and taming them; TikZ translates the transformations for you for specific objects, say transform shape node shapes etc., but if you want to, for example, first scale then slant and rotate then scale back, it doesn't always work in TikZ unless you nest scopes or be very careful issuing them. They are quite easy to handle with \pgfgettransform and \pgfsettransform etc.

• Long path constructions. It's really faster with PGF since the coordinates are not parsed via TikZ.

• There are some undocumented PGF commands such as \pgfmathanglebetweenpoints and a couple of more ;) Always fun!

-
Nice, thanks. If this is the kind of answer that has to be taken "with a grain of salt", then I guess I like my answers nice and salty ;) –  Philipp Jul 22 '13 at 20:38
@Philipp :-) Thank you. –  percusse Jul 23 '13 at 6:44
In the latest CVS version of TikZ/pgf (since 2013-07-19), \pgfmathanglebetweenpoints and \pgfmathanglebetweenlines are now documented. –  Paul Gaborit Jul 29 '13 at 14:19
@PaulGaborit Oh great, thanks for the update. –  percusse Jul 31 '13 at 3:22
add comment