[Tikzdevice-bugs] Two subsequent color def?

[Charlie Sharpsteen]

On Fri, Apr 15, 2011 at 1:02 PM, Cameron Bracken
<cameron.bracken at gmail.com>wrote:

> On Fri, Apr 15, 2011 at 10:50 AM, Charlie Sharpsteen
> <chuck at sharpsteen.net> wrote:
> > On Fri, Apr 15, 2011 at 1:29 AM, Matthieu Stigler <
> > matthieu.stigler at gmail.com> wrote:
> >> Hi
> >>
> >> I notice that the .tex generated contains many lines where the same
> color
> > is
> >> defined twice:
> >>
> >> \definecolor[named]{drawColor}{rgb}{0.66,0.43,0.04}
> >>
> >> \definecolor[named]{drawColor}{rgb}{0.00,0.00,1.00}
> >>
> >>
> >> While the second lines is the one I wanted, the first contains a color
> > that
> >> I did not specify (in my case a brown). Where does it come from ? Can
> one
> >> prevent theis supplementary color to come?
> >>
> >> Thanks!!
> >
> > Hi Matthieu,
> >
> > The code that is responsible for handling style definitions, such as draw
> > colors, fill colors, etc, is fairly old.  Sometimes it defines colors
> that
> > do not end up being used. In many places it also defines the same color
> > multiple times which is inefficient. The style definition code does need
> to
> > be re-worked to address these issues---but as long as the right colors
> end
> > up being used for plot elements it is not causing any bugs and is just
> > making the TeX compiler work a little harder.
> >
> > It would be interesting to see the performance effects of some changes on
> > the runtime and memory use of TeX:
> >
> >
> >   - Ensuring that each color only gets defined once and gets assigned a
> >   unique name.
>
> I think I tried to do this originally but was eventually pushed toward
> the current behavior because of scoping. If a color is defined in a
> scope, then it will get destroyed when the scope is ended.
>

Right, this would require modifying the graphics device to store the plot
output as some sort of tree-like structure. The color information would be
defined in the top level of the tree so it would be outside of every scope.
 There's a lot of neat things we could do if the device was set up this way,
such as throwing out branches that dont contain any graphics items (grid
graphics create a lot of these empty clipping scopes it seems), but it would
take a lot of work.



> >
> >   - Or, inlining each color definition into the path that it affects.
> >
> > Right now, the tikzDevice receives graphics commands from R, translates
> them
> > to TikZ code and immediately writes the result to a file.  If we were to
> > store the graphics commands in a data structure and wait until the device
> > was closed to write  the code to the file, there are all sorts of
> > interesting optimizations that could be done---similar to what a compiler
> > does when it walks an abstract syntax tree and eliminates dead or
> > inefficient code before writing out it's results.
> >
> > But that sort of work would require a lot of changes to the tikzDevice
> > internals.
>
> And all of it in C, bleh. Unless we did everything as callbacks like
> the RGraphicsDevice package (http://www.omegahat.org/RGraphicsDevice/)
> implements. In that case writing things to an R object would be
> trivial.
>
>
> -Cameron
>