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
