Back in July 2010 we had an extensive discussion of this point: the "first time" you generate a gnuplot graph via gretl on MS Windows it can take an inordinate length of time for the plot to appear. It wasn't clear that "first time" meant the same thing thing in all reports, but the first plot after installing gretl + gnuplot from scratch seemed most reliably problematic.
The discussion was inconclusive; we didn't up with a compelling diagnosis. I think I now have the answer: what's taking so long is the fontconfig library building its initial font cache. This accounts for the ambiguity over when exactly the problem arises, since various system changes can provoke rebuilding of the cache from time to time. In the current Windows snapshot I've rebuilt gnuplot so that it does not call fontconfig, and so cache-building time shouldn't be a problem any more. Windows users, please test! We're looking for (a) absence of any wait of more than a couple of seconds for a plot to appear (should usually be faster than that) and (b) any fallout from this change in the form of font-handling errors (e.g. text on plots appears clipped, with bits of letters missing). For enquiring minds: gnuplot calls the cairo library in its generation of PNG plots, and cairo has two different font-handling "backends" that can be used on Windows: a native win32 one, and FreeType plus fontconfig. In November 2009 gnuplot switched away from using the cairo-win32 backend because it was found to be buggy, with glyphs getting clipped. FreeType plus fontconfig produces flawless plots, but the downside is an occasional long wait as fontconfig (re-)builds its cache. By now, with cairo 1.10.2, the win32 bugs that were spoiling gnuplot PNG output seem to be fixed, hence my experiment of going back to the win32 backend. Allin Cottrell
