LW cvs (3.8.6) image corruption
 

on win 2k3, if the screen gets locked with LW running, when I unlock the computer, any images that were showing on the limewire UI are borked. Stuff that wasn't showing seems ok (other themes' images, the buttons' pressed image, the spinning (searching) lime).

It's actually not just images.. widgets without an image get narfed too. See the combobox. I've seen the scrollbars go weird too.

Locking then unlocking the computer sometimes brings some images back, but not all of them. In general, it seems things just get mixed around when this happens.

It could of course be something I did, so has anyone else seen this?

Do things return to normal after resizing the frame, or after minimizing/restoring? Which version of Java do you use?

Also, it looks like you're using a modified CVS version, as those icons in the 'type' column aren't available in a released version yet, and the search bar is in a very different place. Try using the 3.8.6 as downloaded from our website.

Re: LW cvs (3.8.6) image corruption
 

Hi MamiyaOtaru. Still working on AquaLime or have you given up on it completely.

No, they stay the same. Using Sun java 1.4.1

Quote:

Also, it looks like you're using a modified CVS version, as those icons in the 'type' column aren't available in a released version yet, and the search bar is in a very different place. Try using the 3.8.6 as downloaded from our website.

Naturally it's modified :) That's what I do lol.

Using a straight version of CVS that I haven't modified yet gives me the same effect. The icons in the type column are of course still there: it is not 3.8.6 as downloaded from limewire.com. I know weird stuff happens in CVS sometimes, but figured someone might want to know about it :)
If the images weren't narfed you'd see that the spinning lime is a nice aqua blue color :D I can't be bothered with skins anymore, but everything else is as it was (download arrows, flags in the connection tab, import security files etc) I got bored and decided to apply some of the old changes (with fixes to stay current), but I'm not sure if I'll get around to releasing anything.

I'm thinking about messing with the mp3 player some: I've always wanted to be able to seek :) I made a java prog that lets me do that, so I might get around to using its core for LimeWire's mp3 playback. Could be fun.

image corruption comes from DirectX
 

I experienced similar problems, but this is not a problem of LimeWire directly or of Java.

This comes from an incorrect rendering by your display driver of DirectX drawing operations: your display driver does not serialize correctly these operations if they are not executed in the main thread of the running app, and some operations are colliding each other in the DirectX driver.

(One possible problem is for example that the bottom of the status bar in LimeWire gets rendered all grey when the window is restored from the SystemTray: this comes from the fact that when the window is restored, it first has no title bar or decoration, and the invalidated area does not count the size of this decoration in the first redraw primitive, then the titlebar is added and queues a second redraw request, but there's a strange effect in the display driver that forgets to fix the invalidated area for the redraw operation, so the whole window is greyed when the titlebar and decoration is effectively drawn, but the interior continues to use the screen coordinates computed without the titlebar. I looked into Java sources to see why this happens, but there's no fault here. This comes from a problem in the display driver when combining GDI and DirectDraw drawing operations: the decoration and titlebar is drawn from User32 which uses GDI, and Java uses DirectDraw for rendering the interior of the window).

This happens with various Java applications, but also with some games and other DirectX applications. There's little you can do to fix all of them, but trying to find a newer display driver that complies to the DirectX specification and does not have this multithreading problem. The Java display really depends on drawing operations being executed in a well-defined order, but some drivers freely swap operations that they think are not depending on each other (this happens with some display cards that have parallel processors and incorrect algorithms in the driver to detect collision).

There's one thing you can do however, if you can't fix the display driver: disabling the use of DirectDraw by Java, when starting the Java VM. Because you use the CVS version, this can be added in the run.bat command used to launch LimeWire. This generally fixes the problem, by forcing Java to use the legacy (a bit slower) GDI draw primitives, which are always guaranteed by Windows to be serialized first in the main thread of your app, and also across other applications using GDI.

It's very unlikely that a display driver will not implement GDI correctly on Windows, simply because these drivers don't have to manage the drawing queue themselves.

Known display cards that experiment this type of display corruption problem in all versions of Java since 1.3.1 (the first one which started to use DirectDraw on the Windows port to implement the portable Java2D API) are some old ATI Rage cards, some notebook display drivers, biprocessor display boards such as 3dFX Voodoo-based boards. This problem becomes more visible with Java 1.4 because Java2D is now used much more often within the Java core libraries to implement AWT and all Swing components.

You can't disable Java2D which is now a fundamental part of Java core libraries, but you can instruct it to not use DirectDraw if your display driver cannot serialize correctly both DirectX and GDI primitives.

You could submit some of that to codepatch@limewire.org. I'm working on THEX at the moment (tree hashes etc) and I will probably have it ready by tomorrow or so. - Well it's sort of working already but I wanted to add some tests & so on.

Verdyp: That was an interesting read. And you seem to be right too ;)

3d card is a geforce3 (45.23 detonators), and I have directx9.0b

When I run LimeWire with jdk131, the problem is indeed not there. I never noticed it before because I barely switched over to jdk141 because it seems it's needed for some of LimeWire's newer features (that and I finally gave up on skinLF lol)

adding -Dsun.java2d.noddraw=true to the command used to run LimeWire fixed it for me. I might have to try updating those detonators too :) thanks!

Note that such display corruption also occurs with JDK 1.3.1, but less frequently, because Java Swing components in JDK 1.3.1 are based on AWT which rarely uses Java2D, and this JDK has only an embyonic Java2D implementation which makes little use of DirectX on Windows.

In JDK 1.4, Swing was greatly enhanced to display components with Java2D most of the time, and Java2D has now a very extensive use of DirectX (more precisely its DirectDraw part) on Windows.

There are extensive works in Java to further enhance Java2D and provide better support of DirectDraw on Windows, by using some tricky patches in the way drawing primitives sent to the DirectDraw are queued, to bypass some wellknown bugs in display drivers. The tricky thing is that DirectX and thus DirectDraw has several supported versions in its API, and not all display drivers are available that support the latest DirectX 9 API: many display drivers only support DirectX 7, and don't work properly when DirectDraw is combined with GDI in the same application (this is a serialization problem, difficult to implement in display drivers, because Windows GDI as well as Windows User32 or Shell components do not consistently uses DirectDraw for all their output.

Nevertheless, Java2D's use of DirectDraw is still not completely exempt of bugs, notably when it assumes display driver capabilities which are not always impelemnted in all display drivers. DirectX provides a capabilities API that allows the application using DirectDraw to know if an advanced drawing primitive is supported by the driver. Normally Windows should implement the missing primitives by software using the other primitives supported. But if the DirectDraw application (for example Java2D) selects the hardware acceleration only, to bypass the Windows software emulation, things start to be tricky, as the application must check itself all serialization issues.

One of the problem in Java2D is that it runs within multiple threads, whose synchronization by the display driver is not always consistent.

I think that Microsoft has placed the difficulty of developing display drivers too high, by requiring drivers to support simultaneously GDI and DirectDraw. My opinion is that Microsoft should have better rewritten GDI to use DirectDraw always, so that a display drivers could be written to support only a designated smaller set of DirectDraw APIs, that the core Windows DirectX components should manage and queue directly.

Let's wait for a future DirectX API that will allow simplifying a lot display driver implementations. My opinion is that GDI should now become a complete application of DirectDraw and only DirectDraw if DirectDraw is supported by the display driver (GDI support in display drivers should be left unused in that case).

Note also that you can also avoid the -Dsun.java2d.nodirectdraw=true setting in Java: first try to reduce the display acceleration settings in the Avanced Display Control panel. A Full acceleration means that Windows leaves the driver perform all the drawing APIs it says it supports, even if those APIs are not correctly serialized in the display driver.

The first level just disables the hardware cursor acceleation, further levels disable the bitmap renderers in display drivers, or complex renderers such as the driver's built-in font renderer, the drivers's supported antiscaling smoother, hardware-supported texture/bitmap caching buffers, or hardware supported ICM color converters...

[OT] Tiger in GNU crypto?
 

Is that the codepatch which was submitted yesterday evening? I note that you use the Tiger.java function from org.gnu.crypto. It differs a little from my implementation that I wrote more than one year ago when the GNU crypto API was still not ported to Java.

I just looked at it (shamely it was submitted in RAR format which is licenced, why not ZIP/JAR ?), and looked at the generated code and its performance. My implementation is still faster than the org.gnu.crypto version.

Did you try to replace the blockprocessing functions of GNU's Tiger MessageDigestSPI with my code? (you could keep the interface API, or I may integrate my code in the GNU Crypto framework).

May be I should propose my version (which was posted in the GDF files) to GNU Crypto API maintainers, to exhibit them the performance differences (I had worked a lot on my implementation to maximize the optimization of the generated bytecode compiled with javac).

i get that to im on a mac os9 is there a esey way to stop this for ppl like me who have very little knowledge of this stuf all iv done to lime wire is to un disabil what thay disabiled for mac os9