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

Question

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}

Answer 1

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!