Re: color_radio_property implementation

[Quentin Spencer]

Shai Ayal wrote:
> On 4/26/07, John W. Eaton <address@hidden> wrote:
> > On 25-Apr-2007, I wrote:
> >
> > | On 25-Apr-2007, Michael Goffioul wrote:
> > |
> > | | I wanted to keep the java code quite autonomous and usable outside
> > | | octave. So using the property database within octave was not really
> > | | a solution. Moreover, as java and C++ does not share the same memory
> > | | space, it would have been rather complicated and inefficient to 
> > have the
> > | | properties in C++/octave and have the java part constantly 
> > getting/converting
> > | | values from C++/octave to java.
> > |
> > | OK.
> > |
> > | I think it is unfortunate that we may have multiple implementations of
> > | the code to handle the graphics properties as I think that will 
> > lead to
> > | inconsistencies and some confusion for users.  Is there some way to
> > | avoid that?
> >
> > OK, sorry for freaking out about the license.  As I understand it, the
> > Sun JRE is now free software.  Is all of it free software?  I don't
> > know much about Java, so are there features that we might want to have
> > (for example, GUI tools) that are not free?
> >
> > Currently I see that we have several options for graphics:
> >
> >   * Octave with its property database code (somewhat functional but
> >     increasingly clear that it is very incomplete) and various
> >     backends, possibly based on octplot, yapso, gnuplot, your code, or
> >     some combination.  All but gnuplot use OpenGL.
> >
> >   * Octave with your database code and the Java/OpenGL plotting
> >     libraries.
> >
> > My original reason for wanting to have the database and rendering code
> > separate was to allow the possibility of separate backends.  But the
> > more I think about it, I'm not sure that is the right reason.  Writing
> > a graphics package that is reasonably compatible with Matlab looks
> > like a large job (there seem to be many tricks and complications) and
> > I don't think we have a large enough community that it makes sense for
> > us to split the development among N projects.
> >
> > Also, from a the perspective of many Octave users, graphics is a core
> > feature, so I'm not sure it makes sense for Octave to have multiple
> > graphics backends that all behave in slightly different ways and that
> > all provide differing levels of compatibility.  It would be much
> > better to have only one that we all work on together.
>
> While I agree that one back end is better, I do not like the idea of
> octave depending on JAVA. One of octave's strong points is that simple
> operations don;t need much CPU. It is my impression (and please
> correct me if I'm wrong) that Java imposes a severe performance hit.
> As an example I do all my coding and such on a 256MB RAM, p3 800Mhz
> laptop. I run fc6 on it with all the bells and whistled turned off
> (i.e. no gnome etc...) with as much stuff in text mode as possible. By
> far the largest memory footprint now is firefox, which I find hard to
> replace by text based browsers (I need gmail). I once tried running
> eclipse (java based) and my system ground to a halt.
> Making me run Java just to plot a simple line in octave would make me
> very sad (I like plotting lines in octave). Can someone comment on the
> memory/CPU overhead this would imply?

While we're busy complaining about Java's, let me add that the other 
brand has implemented its GUI in Java, and I think it's slow and ugly 
(the command interpreter is nice and fast, of course).

Quentin