If hash is already in play and isn't expensive, then I'd like to see the checkmark as yes/no, rather than "maybe."

I like the idea of multiple meanings (coloured checks), but suspect this adds "unecessary" complexity.

I found the hash column under audio options, but no hash showed for images. Perhaps extending the hash display for other files would be an interim solution?

That's an excellent idea, et voila -- I'm surprised no one has thought of it so far. It's be terribly difficult to implement, but it's a damn fine idea.

Merci Sam, however my upload idea was much better as I recall. I was in the metro this morning, thought about that then I fell asleep because there was still 10 stations to go. Didn't think about it afterwards... so I forgot it. It's frustrating

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/

In fact, after adding some debugging options in Java 1.4.2, OpenGL is ALSO enabled on that version (and I can see the warning displayed on the Console with Java 1.4.2 too)

I have seen yesterday the option "-Dsun.java2d.opengl=true" added in run.bat, and I have already tried to set it to false.
This has NO effect: the OpenGL pipeline is still used, on both Java 1.4 and 1.5 (where I see the warning on the console).
And images are still improperly displayed.

The kind of image corruption I get is when MULTIPLE distinct images need to be refreshed on the screen at the same time: this affects graphic buttons that are all refreshed at the same time, for example when the window is minimized then restored, or when moving the mouse across a row of buttons (one button needs to have its border flattened, and another needs to have its border raised, so both buttons need to be redrawn, and they will both display the same image, one is correct and the second is not).

I really think that this is not a OpenGL bug, but a synchronization issue within the new L&F theme manager (from jgoodies.com), where there's a shared instance whose member points to the image to refresh.

I DON'T have this issue with the current release of LimeWire 4.0.8 or even with Limewire beta 4.1.1 (without the jgoodies L&F), either on Java 1.4 or 1.5, but only with the current development version (4.1.5+) on both versions of Java.

The OpenGL message only appears since some recent beta version, when jgoodies L&F were enabled; and since then the images are incorrectly rendered, the display is desynchronized, and:

In addition when I move the window on the screen, all components are displayed at the wrong place, or the GUI freezes, sometimes Windows will hang. I really suspect that jgoodies-Looks needs its code to run only in the main GUI thread, and that it sollicitates some OpenGL functions which are not properly synchronized and can hang Windows completely if it is used out of the main thread.

Note that I tested the jgoodies Looks demo separately without problem (in addition, without the OpenGL warning on the console). So I suspect that the integration of jgoodies Looks in LimeWire breaks some assumption about multithreading safety.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

It's actually because the setting of openGL got inserted into the gui's Main class. It'll be removed in a few hours.

I just noted that a few minutes ago and I was about to write about it. It's a bad idea to force a system property hardcoded in the code. I did not notice this addition in Main.java until one hour ago, when I commented it out in Main.java, and recompiled.
Now LimeWire works again perfectly without it (of course I have removed the forced property set on the command line in "run.bat", which was also added).
I think that these system properties, if they are needed, should be set manually by users, in their VM settings. However, given that LimeWire on Windows ships with its own VM instanciation program (limewire.exe) and that I doubt it will read and inherit from system properties that have been parametered in the Java Control Panel, may be we could (on Windows at least where the LimeWire.exe runner is used) enhance the LimeWire.exe launcher to get system properties from global Java settings on that machine (this would allow using the standard Java Control Panel to set such properties if needed).
This is too much an advanced setting, which may be useful only on platform that have problems with DirectX drivers, and that can be solved by setting Java2D to use OpenGL instead.

My display board is a Radeon Mobile 9600, a quite recent one, with the most up-to-date drivers certified compatible with Windows XP SP2 and DirectX 9c, and with much hardware support for OpenGL operations. However, OpenGL support in display drivers is often much less tested today. I think there may be a problem within my display driver for its support of OpenGL, or bad assumptions about OpenGL capabilities within the OpenGL support libraries of Java.

I have just tested a few OpenGL apps on my system, and found no such problems, so the problem seems specific to Java2D's use of OpenGL on Windows. So I think that the bug is within the so-called "OpenGL pipeline" managed internally by Java2D. Visibly, not all OpenGL operations made by Java2D are not properly pipelined, and Java2D suffers various synchronization issues with asynchronous OpenGL operations performed by hardware, even if the pipeline is used to serialize these operations in a single internal Java2D thread.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Hummmm.... Lots of bugs in the Sun Bug Database related to its support of OpenGL: most complain that OpenGL was mainly tested by Sun on Windows only, but with much less efforts for Linux.

Support of OpenGL for Linux is very recent, but still bogous, only in Tiger beta, where this is the only "portable" solution to have hardware acceleration for Java2D, because there's no DirectX on Linux. On Linux, there's an alternate interface for hardware acceleration, DCA, but its support in Linux kernels is still too much embryonic and much less widespread than OpenGL.

So may be we could enable and try OpenGL on Linux only, where it significantly improves the display speed, but it will not work correctly before Java 1.5 is officially released, and it won't work with Java 1.3 which is shipped with most Linux installations (including RedHat and SuSE). I think it's safer to keep the default support through DirectX, which is the prefered interface for most games on Windows, and on which most manufacturers have invested their development efforts. OpenGL remains a secondary interface for Windows, and Microsoft offers very little help for its effective support.

For Mac OSX users, this is not an issue: Java2D is ported independantly by Apple using the Mac drivers architecture.

Look into the Sun Java Bug Database for "OpenGL ATI Java2D", you'll see lots of issues. ATI boards are very common on PCs (including GeForce and Radeon models), and it's up to Sun to find a reliable way to work with ATI's OpenGL drivers on Windows. For now it does not work reliably.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Yup, we're not gonna enable openGL. It was in there by accident.

Thanks Sam. Sun officially says that OpenGL is still not supported in Java. The system property is only there in Tiger-beta for developers that want to test their apps and that want to help Sun with bug reports.
Sun is not even sure it will be ready and enabled in the final release of Java 1.5 for Windows (but OpenGL will be supported in Jav2D on Solaris, and probably on Linux). The support of OpenGL is being developed for a later better integration of Java3D in a future release of Java.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Surely in the interests of open networks and file sharing - we should not be re-naming ANY files we are keeping in public view. Am I right?