Re: color_radio_property implementation

[Shai Ayal]

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?

Shai