Phil, The problem was that we updated the API and added new functionality that was never included in the metafiles since no-one was supporting it. In the end we took the decision to disable it by default rather than distribute something that didn't work fully. The plrender code is still there in utils/ if you want to take a look. It would be possible to resurrect this is someone was enthusiastic enough.
I always had it in the back of my mind to do a complete rewrite to make an object oriented structure storing all the plot information. This would allow complete recreation of a figure, and also allow editing of labels, data, colours etc. My vision was to implement something that would allow creation of proper matlab style graphics in octave, but it would be useful for other things too. Of course other things got in the way and I never had time for this project. It's still out there as an idea though... Andrew On Fri, Jan 09, 2015 at 03:55:27PM +0000, Phil Rosenberg wrote: > Hi Jim > Thanks for that info. > > I have done a bit of googling and it seems that there also used to be a > tool called plrender which read in metafiles - however I found an email > from Alan in 2007 ( > https://www.mail-archive.com/plplot-general@lists.sourceforge.net/msg00177.html) > saying that the metafile device had fallen into disrepair. Presumably if > that never got fixed then plrender stopped being useful also and was > eventually removed. > > As you say it should be relatively easy to reinstate the two to some > degree, however I can't remember how things like fonts get buffered - i.e. > is the decision about Hershey fonts made before buffering or does it make > no difference? The easiest way would just be to introduce something like a > plsavebuffer and plloadbuffer or plgetbuffercontents and > plsetbuffercontents into the public API, but that then requires propagation > through all the other languages. > > However, I imagine that I will suffer the same slowdown you experienced so > maybe there is a better way - unfortunately all the better ways I can think > of (transport via a network port, or shared memory) are either much more > difficult or not very platform independent or both. For now don't worry > about it. I will mull things over and see what I can think of as the best > way to do this. > > Phil > > On 9 January 2015 at 14:42, Jim Dishaw <j...@dishaw.org> wrote: > > > I believe those BUFFERED_FILE blocks are from the patches I submitted > > years ago that implemented the memory buffer. > > > > Prior to that patch, Plplot used a temporary file to buffer plot commands > > (using a plplot internal command set). Those temporary files would often > > get left behind on abnormal termination. I implemented a memory only buffer > > (which also sped up my code) but I wanted to leave the original temporary > > file buffers in case someone was using plplot on a low memory machine. > > > > The contents of the memory buffer is (or at least was) identical to what > > was in the temporary file. It would be relatively easy to implement two > > routines that read and write the memory buffer. If you want I can do that > > and send you a patch. > > > > > > > > On Jan 9, 2015, at 4:58 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> > > wrote: > > > > Hi all > > > > Does anyone know if the metafile driver still exists and if so what CMAKE > > parameters are needed to enable it - I currently don't get it for my builds. > > > > Also is there an easy way to read a plplot metafile in again? I see quite > > a few #ifdef BUFFERED_FILE comments in plbuf.c, which look like they do > > exactly that, however it looks like a build can only either use a memory > > buffer or a file buffer, not both. > > > > Just for background I'm trying to deal with the wxWidget driver segfault > > bug, which requires the wxWidgets app to run in a separate thread or as a > > separate process. As plplot isn't threadsafe I am looking into the latter, > > but I need a way to send commands from the console app to this separate > > process - I was thinking that the easiest way to do this would be to write > > out the buffer, then read it back in again. Thoughts welcome. > > > > > > Phil > > > > > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming! The Go Parallel Website, > > sponsored by Intel and developed in partnership with Slashdot Media, is > > your > > hub for all things parallel software development, from weekly thought > > leadership blogs to news, videos, case studies, tutorials and more. Take a > > look and join the conversation now. http://goparallel.sourceforge.net > > > > _______________________________________________ > > Plplot-devel mailing list > > Plplot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
