Often, rendering graphics is a very disconnected process from the editing of the \TeX\ source. First, the author must write or edit a .tex file, that contains the source to generate the graphic, usually describing the digram using PSTricks or TikZ. The author then runs a series of commands to generate a PostScript or PDF file, which they can then open to preview the results. For example, to render a latex document often requires use of terminal and you may use these commands:

\begin{verbatim}
latex paper.tex
dvipdfm paper.dvi
xpdf paper.pdf
\end{verbatim}
That required {\it three} steps in order to view the actual graphic. But that is not the only step required by the user. They also have to context switch between the text editor and the terminal and the graphics display program. The process then becomes more fragmented. Here is a graphic where each arrow represents a context switch:


\psset{unit=1.5cm}
\begin{center}
\begin{pspicture}(-1,-2)(6,2)

\rput(0.5,0.5){text edit}
\rput(2.5,0.5){compile}
\rput(4.5,0.5){preview}
\rput(2.5,-1.25){repeat if needed}

\psframe(0,0)(1,1)
\psline{->}(1,0.5)(2,0.5)
\psframe(2,0)(3,1)
\psline{->}(3,0.5)(4,0.5)
\psframe(4,0)(5,1)
\psline(4.5,0)(4.5,-1.5)
\psline(4.5,-1.5)(0.5,-1.5)
\psline{->}(0.5,-1.5)(0.5,0)


\end{pspicture}
\end{center}

The user has a series of steps within these contexts:

\begin{enumerate}
\item switch to text editor
\item edit the .tex
\item switch to terminal
\item run {\tt latex} command on .tex file
\item run {\tt dvipdfm} command on generated .dvi file
\item open preview the pdf
\item if the graphic is incorrect, repeat
\end{enumerate}


\psset{unit=1cm}
\begin{center}
\begin{pspicture}(0,0)(9,2)

\rput(1.5,1){.tex}
\rput(4.5,1){.dvi}
\rput(7.5,1){.pdf}
\psframe(0.5,0.5)(2.5,1.5)
\psline{->}(2.5,1)(3.5,1)
\psframe(3.5,0.5)(5.5,1.5)
\psline{->}(5.5,1)(6.5,1)
\psframe(6.5,0.5)(8.5,1.5)

\end{pspicture}
\end{center}

This process takes anywhere from seconds to minutes. If the user must make a change, they have to repeat the entire process which can be frustrating. How can we minimize amount of time and space it takes to render a document? Enable real-time editing and preview.

\begin{interactive}
\img{/app/assets/paper/realtime.png}
\end{interactive}
\begin{print}
\begin{center}
\includegraphics[width=300pt]{images/realtime.ps}
\end{center}
\end{print}

This platform provides an editing experience where the text editor and preview are on the same page, hence, updates appear in real-time within the same context. The real-time authoring aspects allow a user to get instantaneous feedback while creating these diagrams, and making changes becomes simple and the results are displayed right away. 


The user interface continuously evolved. At first, there was a text box that would scroll off the page as you scrolled down the preview content. It make it extremely hard to edit continuously. Then I created a fixed position text area, but then every re-render initially caused the page preview to scroll to the top of the page, so to mitigate this, at the initialization of a {\tt TEX} view, the platform stores a reference to the scroll height and repositions the window accordingly, so the user doesn't have to re-scroll the window to the point of interest. In fact, the experience is seamless now. You can scroll through the text and the preview independently on the same page while editing in real-time. 


Another issue was using {\tt keyup} events to trigger a re-render. Every time the user would type in the text editor, the page would re-render sometimes causing a lag for larger pages. A way to fix this was to use throttling. The framework stores a reference to an id that points to a callback function supplied by a {\tt setInterval} function that has a value of 500 milliseconds. Basically the system then only calls the function every half second, and only then. If a new {\tt keyup} event occurs, it only adds a callback if there isn't a reference to one already. This ensures a streamlined editing experience for the author.


Optimizing the Editing Flow