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).