Porting Violet to Java

[dougal2]

OK I'll check what I have right now...

On windows:
1.6 appears to be installed.

On OSX:
1.5 appears to be installed. However, netbeans won't compile my code.
The errors appear to be swing related.

Code: Select all

... jVioletAboutBox.java:82:cannot find symbol
symbol : class GroupLayout
location : package javax.swing
 javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane());

I thought Java was supposed to be nicely platform independant?
This is really stupid, I don't feel like this is getting anywhere.

I also don't expect the situation on Linux to be any different or easier, what with the rejection of most proprietary code grrr

[ViennaLinux]

here you see their stupid naming scheme: http://java.sun.com/reference/api/

I think you GroupLayout is an new feature of java 6
But I am not sure

[dougal2]

OK, well it's only GUI related - the GUI can be, and probably should be rebuilt anyway. My first layout isn't all that good.

Does java 5 support Generics ? that's the only other recent feature that I know I'm using.

[psor]

Quick question, ... is this for intel only too? ;o)

edit: *Argh* I guess it's not the JDK, just the JRE ... *grmpf*




take care
psor

[dougal2]

OK, here's what I've done...

I removed the JDK6 GUI and rebuilt a basic one (erm, 1 imagePanel and 1 button ) using JDK5.

This project should now work on linux (tested), windows (not yet tested) and OSX (not yet tested).

I've committed my changes.

I'll make sure to set my Windows IDE to use on only java 5/1.5 to make sure it remains compatible.

Phew, that's 2 niggly problems solved this evening

[eman7613]

you gave me the wrong path that was the problem (was trying /mti-jViolet).

Yes, Apple sucks as a java development platform, hopefully the OpenJDK project will fix that.

1.5 has Generics, yes. GrouLayout was in 1.5, its fine.

1.6 has that 1.5 dosn't (from a coding standpoint): SwingWorker with the JRE, a few desktop APIs, a few additions to default swing components, and integretade DB. (there is more but they arnt as related to writing code in java)

Any new CODING featuers in 1.6 generaly came from pre existing librarys on java.net and swinglabs.

Actually, linux is my preffered java development enviroment i like it a lot. in ubuntu, sudo apt-get install sun-java5-jdk, and done

[dougal2]

sorry about that wrong path.... so many three letter abbreviations to rememeber

[ViennaLinux]

please compile it for java 1.5 and dont use java 6.
java 5 supports generics and all the stuff you will need.

I hate creating swing guis because you need a lot of practise and then its still not beautiful code

If you need a tester write me a PM. I can test mac os x and windows for you right now.

[dougal2]

ViennaLinux:
I'm setting the project up to run java 1.5 and it's working

Are you on intel OSX or PowerPC OSX?

I think probably between us we will be able to test most platforms.
I have access to the following
AMD and Intel 32bit: Windows XP 32bit, Ubuntu 7 32bit
Intel 64bit: Windows XP 32bit, Vista 64bit, Ubuntu 7 64bit
PowerPC (G4): OSX 10.4 and Ubuntu 7

[eman7613]

I hate creating swing guis because you need a lot of practise and then its still not beautiful code

im recreating the current GUI from violet right now, will probably be done tonight/customary. The coding can get messey, but netbeans has a realy nice GUI builder and that helps a lot in just organizing everything

[dougal2]

Cool eman, let me know when you want a username/password for the SVN.

[dougal2]

(this post is more of a note to myself than anything)

I've realised what the problem with the tonemapping is, and why it broke when i implemented multi-threading:

On each tonemapping pass, the entire image is scanned to get it's average luminance - and no matter if a thread is processing either the whole image or just a part of it, every thread must scan the whole image, something I saw as a potential slow-down.

So what I did was move the luminance calculation into the image loader routine - this is the error.

The luminance values should be calculated when the tonemapping is performed, not before. I guess we have to live with the fact the whole image needs to be scanned in every processing thread.

What I need to do is re-enable the routines in the Tonemapper superclass, and change a line is each of the XToneMapper subclasses and it should work again.
(and remove the luminance calculation from the image loader).

... that is unless there's another, more clever way around this problem.
[edit: how about:-
upon entering the getAverageLuminance routine, set a class var that tells other threads whether this value is being calculated or not - the first thread to get into this routine calculates the averageLuminance and stores it in the Image instance, and the other threads wait until this single thread has done the work, and simply retrieve the averageLuminance value from the Image instance ]

[dougal2]

ok, I implemented luminance calculation, as per my note above.

when running multi-threads the first thread to call the getLuminance function will scan the whole image, and the other threads wait until it's finished and simply pick up the result.

[ViennaLinux]

cant you find out how many threads the cpu can do and then split the luminance calculation? so lets say 2 threads means one thread is created for the upper part of the image and the second on is for he lower part. of course then you need to sync the results somehow and its more to code.

[dougal2]

solution 1:
yes I suppose the luminance calculation could spawn it's own threads. not a problem.

edit: OR..
solution 2:
each image processing thread goes ahead and calculated it's part of the luminance and waits for the other threads to do their bit, and the last thread to complete sums up the total. then all threads can carry on in parallel.

damn, there's loads of ways this could work. I don't know what'd be more efficient though.
I guess solution 2 is better because it doesn't spawn a whole load of new threads.