From: <so...@sy...> - 2004-11-08 17:12:15
|
I meant implementing native jave APIs similar to plplot APIs rather than java binding. -Ali > > From: Andrew Ross <and...@us...> > Date: 2004/11/08 Mon AM 10:24:17 EST > To: so...@sy... > CC: plp...@li... > Subject: Re: [Plplot-general] (no subject) > > On Mon, Nov 08, 2004 at 09:57:47AM -0500, so...@sy... wrote: > > Hi, > > > > I was wondering if anybody has considered implementing plplot apis into java (java2d or 3d). I am ready to dedicate some of my time for this. My C programming is very rusty. I need help from somebody who is very familiar with the plplot architecture and code. > > > > Ali, > > Can you explain exactly what you mean by this? More or less all the plplot > common API is already available in Java provided you are using the > latest versions of plplot. Which version are you using? > > Regards > > Andrew > |
From: Lehmann, E. {TR-I~Penzberg} <eckhard.lehmann@Roche.COM> - 2004-11-09 06:24:48
|
That doesn't make sense, probably. There are already good plotting API's available for Java - think of JfreeChart (http://www.jfree.org/jfreechart/) or Ptolemy Plot (don't remember the link yet). I think if you want to use PlPlot and only PlPlot, you should use the existing java bindings, test and maybe improve them for your needs - and if you want to use just some plot extension or require to use java2d/3d for plotting, use one of the existing java plot extensions (and test/improve them). Eckhard ;) -----Original Message----- From: plp...@li... [mailto:plp...@li...] On Behalf Of so...@sy... Sent: Monday, November 08, 2004 6:12 PM To: Andrew Ross Cc: plp...@li... Subject: Re: Re: [Plplot-general] (no subject) I meant implementing native jave APIs similar to plplot APIs rather than java binding. -Ali >=20 > From: Andrew Ross <and...@us...> > Date: 2004/11/08 Mon AM 10:24:17 EST > To: so...@sy... > CC: plp...@li... > Subject: Re: [Plplot-general] (no subject) >=20 > On Mon, Nov 08, 2004 at 09:57:47AM -0500, so...@sy... wrote: > > Hi, > >=20 > > I was wondering if anybody has considered implementing plplot apis=20 > > into java (java2d or 3d). I am ready to dedicate some of my time for this. My C programming is very rusty. I need help from somebody who is very familiar with the plplot architecture and code. > >=20 >=20 > Ali, >=20 > Can you explain exactly what you mean by this? More or less all the=20 > plplot > common API is already available in Java provided you are using the > latest versions of plplot. Which version are you using? >=20 > Regards >=20 > Andrew >=20 ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Plplot-general mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Andrew R. <and...@us...> - 2004-11-09 12:52:40
|
On Tue, Nov 09, 2004 at 07:24:42AM +0100, Lehmann, Eckhard {TR-I~Penzberg} wrote: > That doesn't make sense, probably. There are already good plotting API's > available for Java - think of JfreeChart > (http://www.jfree.org/jfreechart/) or Ptolemy Plot (don't remember the > link yet). I think if you want to use PlPlot and only PlPlot, you should > use the existing java bindings, test and maybe improve them for your > needs - and if you want to use just some plot extension or require to > use java2d/3d for plotting, use one of the existing java plot extensions > (and test/improve them). > > > Eckhard ;) > The philosophy of plplot has always been to develop a standard API of plotting routines. Through the bindings we attempt to support as many different languages as possible, all with a similar interface. There is no way we could do this by reimplementing the same code in each different language, we just don't have the resources and it would make maintenance a nightmare. For some languages we do add some extensions to the API to make use of the object orientated nature of the language or of specific array handling syntax for example. The java implementation does attempt to make the plplot API more object orientated. Through the various drivers we provide support for different output devices. Now there is probably no reason you couldn't implement a java plplot widget (similar things have been done for Gnome under Linux) if this was the kind of thing you were interested in. If you have any ideas about this then feel free to suggest them or provide code. Please remember though that we would like to keep some uniformity between bindings and that ease of maintenance is important. Cheers Andrew |
From: Lehmann, E. {TR-I~Penzberg} <eckhard.lehmann@Roche.COM> - 2004-11-11 07:40:30
|
Andrew - > The philosophy of plplot has always been to develop a > standard API of plotting routines. Through the bindings we=20 > attempt to support as many different languages as possible,=20 > all with a similar interface. There is no way we could do=20 I like this philosophy. From Ali's mail I understood that he wants/needs to use Java2D/3D for plotting rather than native code - because he was writing about reimplementing Plplot for Java2D/3D, which means reimplementing in pure Java. That doesn't make sense in my opinion, Plplot is good as it is (at least its philosophy, more on this later) and if one wants to use pure Java, she should take a look at existing plotting devices in pure Java. I use Plplot for displaying very large amounts of data in XY line plots, up to 150,000 points. Therefore Plplot and for me the Tcl/Tk interface is a good choice - simply because my application will run on "old" hardware as well. Plotting these data with pure Java is definitely slow on i386 platforms with only about 1 to 1.8 GHz frequencies. Besides that Plplot is for simple plotting more suited and not as complex as e.g. JFreeChart. > Now there is probably no reason you couldn't implement a java > plplot widget (similar things have been done for Gnome under Linux)=20 > if this was the kind of thing you were interested in. > If you have any ideas about this then feel free to suggest them or=20 > provide code. Please remember though that we would like to=20 > keep some uniformity between bindings and that ease of=20 > maintenance is important. That would be a good idea, I have some proposals and I can imagine to provide code as well as soon as I got the time to do so. I was starting with Plplotter for Tcl/Tk on windows - At this time it was for me the only useful interface. But I would prefer Java in the end (not before this week I heared that the Java interface is half way useful on Windows too).=20 As soon as I have time left I could start to test and use the java Plplot binding, maybe implement a Java plplot widget similar to the plframe command in Tcl/Tk, and as well make contributions to the project. For now I have some things in mind already that seem generally important (not only for java) from my point of view: - automatically axis and label scaling for zoomed plots. It should be possible to have the scales of a plot automatically adjusted and visible to the data in a zoomed plot window rather than have them zoomed together with the entire plot. The same applies to data labels inside the plot - currently they are resized to the same ratio the whole plot is resized in a zoom operation and that looks 'uahhbrrrr'. I wrote a mail to the list regarding this some time ago... - more than 16 colors. I have heard that the plot window is 16bit (?). It would be interresting to coose any color from the normal rgb palette and have 32bit colors. Eckhard ;) |
From: Alan W. I. <ir...@be...> - 2004-11-11 17:07:12
|
On 2004-11-11 08:38+0100 Lehmann, Eckhard {TR-I~Penzberg} wrote: > - more than 16 colors. I have heard that the plot window is 16bit (?). > It would be interresting to coose any color from the normal rgb palette > and have 32bit colors. Our R, G, and B values are stored in 8-bit unsigned integers so our fundamental colour limit is we have 24 bits of colour with no transparency channel. It's been quite a while since I did a bunch of experiments with the png, jpeg, and gif devices associated with the gd.c device driver, but I recall they supported a large number of different colours and perhaps even up to our theoretical maximum of the full 24 bits. I doubt the other older devices go that high, but if you needed more colours for them, I don't think it would be that difficult to change them. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Lehmann, E. {TR-I~Penzberg} <eckhard.lehmann@Roche.COM> - 2004-11-12 06:35:02
|
>=20 > Our R, G, and B values are stored in 8-bit unsigned integers=20 > so our fundamental colour limit is we have 24 bits of colour=20 > with no transparency channel. It's been quite a while since I=20 > did a bunch of experiments with the png, jpeg, and gif=20 > devices associated with the gd.c device driver, but I recall=20 > they supported a large number of different colours and=20 > perhaps even up to our theoretical maximum of the full 24=20 > bits. I doubt the other older devices go that high, but if=20 > you needed more colours for them, I don't think it would be=20 > that difficult to change them. That should suffer, of course. It seems that I haven't figured out how to set the colors yet, I'm still using the predefined plcol0 palette with 16 colors, the documentation did not offer to me a real alternative (except that it should be possible to change these colors... But how?). May I ask for a short example how to do this from within Tcl? Eckhard ;) |
From: Alan W. I. <ir...@be...> - 2004-11-12 07:27:24
|
On 2004-11-12 07:34+0100 Lehmann, Eckhard {TR-I~Penzberg} wrote: >> >> Our R, G, and B values are stored in 8-bit unsigned integers >> so our fundamental colour limit is we have 24 bits of colour >> with no transparency channel. It's been quite a while since I >> did a bunch of experiments with the png, jpeg, and gif >> devices associated with the gd.c device driver, but I recall >> they supported a large number of different colours and >> perhaps even up to our theoretical maximum of the full 24 >> bits. I doubt the other older devices go that high, but if >> you needed more colours for them, I don't think it would be >> that difficult to change them. > > That should suffer, of course. It seems that I haven't figured out how > to set the colors yet, I'm still using the predefined plcol0 palette > with 16 colors, the documentation did not offer to me a real alternative > (except that it should be possible to change these colors... But how?). > May I ask for a short example how to do this from within Tcl? This is documented in http://plplot.sourceforge.net/docbook-manual/plplot-html-5.3.1/color.html . "For more advanced use it is possible to define an arbitrary map0 palette of colors. The user may set the number of colors in the map0 palette using the command-line ncol0 parameter or by calling plscmap0n. plscol0 sets the RGB value of the given index which must be less than the maximum number of colors (which is set by default, by command line, by plscmap0n, or even by plscmap0). Alternatively, plscmap0 sets up the entire map0 color palette. For all these ways of defining the map0 palette any number of colors are allowed in any order, but it is not guaranteed that the individual drivers will actually be able to use more than 16 colors." If you click on any of the command links from the above URL you will get complete documentation of the C argument lists which are straightforward to transform to tcl syntax using the C and tcl examples as a transformation template. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |