@Jim
Thanks for the hint about plbuf_switch() I will check that out.
Regarding your options. My preference would tend towards 3, which is the option
you like least. My reason is that the previous plmeta driver failed because it
wasn't maintained, but plbuffer should be maintained as it is used by other
drivers and is part of the public API. Therefore reuse of this code is
essential to keeping plmeta file maintained. For wxWidgets I have basically
copied the buffer between 2 processes via a chunk of shared memory.
@Alan
The wxWidgets driver is nearly done now. The last part is just putting posix
named semaphores in where I have used windows named mutexes. So I have a few
questions
1) Do you want another patch to try before I commit to the repo.
2) when I commit do you need me to condense the (considerable) number of
commits in my private repo.
3) as mentioned above. I am using Posix named semaphores which I think only
became available in kernel version 2.6.something. Do you know if there is a way
to check for them in CMake? If it is easy for you to do I'd really appreciate
that contribution as you know cmake so much better than me.
4) There is reference to pls->LocateEH() in the old wxWidgets driver, however,
searching with fgrep -Rl LocateEH I only found this in plstrm.h, tek.c, tk.c
and xwin.c, so I assume this callback is defunct? If you know otherwise let me
know.
Phil
-----Original Message-----
From: "Jim Dishaw" <j...@dishaw.org>
Sent: 10/02/2015 17:17
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
Cc: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>;
"plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
On Feb 10, 2015, at 10:07 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> Hi Alan, Jim and all
>
> I have had to rework some of the new wxWidgets driver to allow
> plGetCursor to work. SOme obvious extra challenges presented
> themselves when I realised how this function worked, such as two way
> communication via shared memory and synchronisation of this resource
> via mutexes, the ability to render a plot part way through and block
> while we wait for input. But the extra work has resulted in a better
> design and a better experience, e.g. multiple pages being able to be
> shown in one frame, the ability to move backwards as well as forwards
> in in page number.
>
> However, one negative of the changes is that I need to be able to pass
> a buffer into the plplot driver. This is obviously very close to the
> issues with the file input we discussed before.
>
I am assuming you need to be able to pass a plot buffer to have the plot
displayed.
> Basically I wanted to see if anyone had any suggestions for the best
> way to do this, the options as I see them are:
>
> 1) via a pl_cmd call which is dealt with within the plplot core code.
> 2) via a special driver, then a pl_cmd call which is dealt with in
> this driver then a plcpy call
> 3) via a modification of the file input method
> 4) via a pl_cmd call which is dealt with in the wxWidgets driver
> 5) via an API change.
>
<snip>
>
> Anyway, any thoughts? My default thinking for now is to do 1 (or
> perhaps 2 depending on if I split the existing wxWidgets code), then
> when we get the file input sorted convert to 3.
>
There is a plbuf_switch() function in the plbuf that is only unused by the
gnome canvas widget (gcw). I think it might do what you want. I am grappling
with how to implement plot metafile I/O, so we should think of what we need to
implement. My current thoughts are as follows:
Option 1:
1) Consolidate the plot metafile I/O into one file (src/plmetafile.c)
2) Make the plmeta driver essentially a do-nothing except for BOP and EOP.
3) The metafile I/O would read/write from/to the plot buffer.
4) The plmetafile.c module is responsible for handling the data in a portable
format (and handling different versions)
5) The plot buffer would be kept simple (e.g. not portable) for speed
Pros:
1) All plot metafile I/O is one file
2) Does not require a new stream to write a plot metafile
Cons:
1) Either plot buffer reading/writing would leak outside of plbuf.c or plbuf.c
would need to provide an internal API
Option 2:
1) Use the plmeta driver for writing plot metafiles (a command line switch to
save would invoke this driver)
2) Plot metafile input would reside in a separate file (src/plmetafile.c)
3) The plmeta driver and plmetafile input module would handle the data in a
portable format
4) The plot buffer would be kept simple (e.g. not portable) for speed
Pros:
1) Writing plot metafiles is a bit simpler
2) Similar to what is implemented now
Cons:
1) Either plot buffer reading/writing would leak outside of plbuf.c or plbuf.c
would need to provide an internal API
2) Forces the use of a new plot stream to save a plot metafile
Option 3:
1) The representation used by plbuf is identical to a plot metafile
2) The plmeta driver is essentially a do-nothing
Pros:
1) One representation of plot data
2) I/O is very simple
Cons:
1) Performance
I am equally divided between options 1 and 2. I think option 3 is a bad idea.
I think option 2 is slightly better because the same mechanism could be used
for saving an output or generating a hardcopy when using an interactive GUI
driver like wxWidgets. Why have two different output mechanisms?
Depending on what is needed for wxWidgets, the balance may shift towards one of
the above options.
------------------------------------------------------------------------------
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
