No problem. Let me know how I can help out. If you wanted to enable the
capability to select temporary files vs memory buffer at runtime, the #ifdef
could be changed to if blocks. However, that would require a flag variable to
denote which one to use. I would recommend against that because it would add
to the complexity for very little gain. I think your idea of implementing
plsavebuffer and plloadbuffer is the better path.
If I recall correctly (and I checked the code quickly), the Hershey font setup
occurs outside the buffers (both memory or temporary file). The buffers just
stores the text. So, the decision to use Hershey fonts has to be made before
rendering on the output device. However, one could replay the same buffer for
different output devices and font configurations. Printing in the Windows
driver works by replaying the buffer.
On Jan 9, 2015, at 10:55 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> 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
