Strange Java2D painting problems...
Hi All, I am having some strange Java2D painting problems that I am unable to reproduce on Solaris or WindowsNT, so I am assuming from this (perhaps erroneously) that it's a porting issue. Has anyone else noticed black blocks appearing (and dissapearing) inside Graphics2D areas when objects are moved around near diagonal antialiased lines? You can see why I didn't put a formal bug report in yet. I'm still investigating it (and mostly putting up with it). I have a rather complicated program which uses the DIVA graph library that exhibits the problem. In fact, the diva.graph.demo.GraphDemo application can easily be made to show the problem. Eventually after dragging around for a while, the application will crash the JVM with a segmentation fault. Anyway, I'd love to help track down this problem. Java2D under Linux could be much better. I even tried green threads versus native, JIT and no JIT, and the problem shows up in all cases. Cheers. -Neal -- + Neal Sanche ++ [ [EMAIL PROTECTED] ] +-- ICQ 5516171 --+ Trifles make perfection, and perfection is no trifle. -- Michelangelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange Java2D painting problems...
> I notice the problem too. Using java2D, my application will crash > the JVM with a segmentation fault too. I also notice that when I > move the window while the JVM is still loading or painting, the JVM > crashes. So, I think the problem may be complex, anyway I think > this is a port problem. Thanks for the second pair of eyes, and the vote of confidence that I am not insane. I don't have time right now to put in a report with sample code to reproduce the problem, but I will still make a formal bug report soon. -Neal -- + Neal Sanche ++ [ [EMAIL PROTECTED] ] +-- ICQ 5516171 --+ If we spoke a different language, we would perceive a somewhat different world. -- Wittgenstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Memory Leaks with jdk1.2pre2
I am also seeing memory problems with JDK1.2 pre2. I am running RedHat 5.2, glibc 2.0, and was not seeing this behaviour with jdk1.2pre1. I have also tried RedHat 6.0 under VMWare under Redhat 5.2 and the GlibC 2.1 version has the same behaviour. If you are interested to see if it behaves the same on your system, try out the test program: http://www.nsdev.org/test2d.jar By running it: java -jar test2d.jar On my system, if I drag the nodes around on the screen, the memory will eventually be exhausted, or there will be a deadlock. There are also other bugs with the 2d system that can be shown by dragging the node closest to the bottom of the screen from side to side... I'd be interested if that happens on anyone else's system. It doesn't happen in Windows, or on Solaris jdk1.2 ports. Under RedHat 5.2, with XFree86 3.3.3.1 when dragging I sometimes get black blocks appearing on the screen near diagonal antialiased lines. Surprisingly this does not happen under my RedHat 6.0 installed under VMWare, go figure. The program does exhibit the memory leak and deadlocking under both setups though. Like I mentioned, this memory leak does not happen under jdk1.2pre1. If you want to play, hold down the control key, and start putting more nodes on the screen by left clicking the mouse... then drag between the nodes to make more links. The more links, the faster the memory goes away. :I Diva is found at: http://ptolemy.eecs.berkeley.edu/diva/index.html Cheers. -Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xdelta of the Sun jdk1.2.2rc1 -> jdk1.2.2rc2
Hi All, Well, if you're like me, and disturbed by having to download 21MB of information over a slow link everytime Blackdown or Sun release a new version of their JDK bundle, then I have news for you. I'll be attempting to build, and maintain a set of xdelta files to go from one version to the next version of some of these big files. I have started with the Sun version. So you can go: From: jdk1_2_2rc1-linux-i386.tar.gz To: jdk1_2_2rc2-linux-i386.tar.gz With: ftp://gonzalez.cyberus.ca/pub/Linux/jdk-1.2.2-sun/rc1-rc2.xdelta Using the following command: xdelta patch rc1-rc2.xdelta jdk1_2_2rc1-linux-i386.tar.gz \ jdk1_2_2rc2-linux-i386.tar.gz The nice thing is, the xdelta is only 1MB. Maybe Sun and Blackdown would like to do this xdelta processing on my behalf? It would certainly be convenient for those of us with slow connections. (Some of us live in 'retro' areas, still untouched by the hand of progress.) PS: If you don't know what I'm talking about here, don't ask. :) PPS: xdelta 1.1.1 is located at: http://www.xcf.berkeley.edu/~jmacd/xdelta.html -Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TYA incompatible types
SHUDO Kazuyuki wrote: > TYA 1.6 has been already released. Try it. > You will be able to get it on the following pages: > ftp://gonzalez.cyberus.ca/pub/Linux/java/ > http://www.dsv.su.se/~jens-and/tya/ > I have to announce that gonzalez.cyberus.ca is no longer available. I had originally put the gonzalez machine up on the net at my service provider, but it became unstable, and was taken off the network and put behind a firewall. It was a pleasure serving all of you Java Linux guys for the last few years. Cheers. -Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1.2.2 vs 1.3.0
On Friday 20 April 2001 08:11, Brett W. Smith wrote: > I have been using blackdown's 1.2.2 FCS for over a year now, with native > threads, JNI, RMI, and JINI. I have been asked to upgrade to 1.2.2, and > am looking for issues related with my upgrade. Any feedback is much > appreciated. > > 1) Sun's 1.3.0 rpm vs Blackdown's 1.3.0 (performance, bugs, etc.) I can respond to point 1. I have been using the Blackdown 1.3.0 FCS version since it was released and have been quite happy with its stability. Notably it works around some issues with the KDE 2.1 window manager (kwin) that I have noticed seems to stump the Sun JDK. Although it's still not perfect in its handling of screen placement of windows. The effect is quite noticable with KDE and the Sun JDKs, including the latest 1.3.1 release candidate from Sun. JOptionPane windows jump from being centered to being in the top left corner of the screen and alternate. First one will pop up centered as it should, then the next will be top left... and so on. Apparently the KDE developers have put a workaround into KWin that will be released later this year so that KDE responds to the JDK's query about what kind of window manager it is by saying it's a CDE compatible window manager, which the JDK (sun's or blackdown's) handle more closely to how it should. Performance wise, I think both are close, I haven't noticed anything strikingly obvious. Other than the window placement, and window sizing issues, both JDKs work quite well under Linux, which is nice compared to the dark years past where only the kind folks from Blackdown, and before blackdown pulled the JDKs with their own steam for so long. Now at least Sun is giving decent effort to it. It can only get better from here. -Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JNI Multithread Question in Linux
On January 7, 2004 10:37 pm, Paul Mclachlan wrote: > Kok Choon Kiat wrote: > > It appears to me that the native thread has *seized the entire > > flow of control* from java program and it is not running > > independently. Why is that so? How can I make the native thread > > independent and not seize the flow of control from the java > > program? I would really appreciate if you can my answer my > > questions. Thank you very much. > > Add a "System.exit( 0 );" to the end of your main() method. > > When main() ends, all that means is that that thread has finished. > If your process has other (non-daemon) threads running, it will > continue to run until they finish, also. Unless you hard-terminate > the process. > > If you're trying to prove a point, you could add a random sleep in > before calling System.exit(0), then you'd see nondeterminism at > work and could be happy that it was doing what you wanted. > > On the other hand, if what you're after (and I can't tell from your > email, sorry), is that the "Hello World"'s keep printing even after > the java process has exited, you need a Runtime.exec() or fork(), > not a pthread_create(). I suspect you know this, but thought I'd > throw it in just in case. I agree with what Paul said above and would also add that I recently read that one of the more recently JDK 1.4 versions also added the ability for Native threads to be 'daemon' threads. Which means the JVM will exit even if they are running. What JJ is seeing is a non-daemon native thread keeping his JVM from exiting, and I think he was surprised by that. Oh well, fun stuff to think about, but not exactly anything concerning Linux, other than the fact that it was the platform on which the behaviour was observed. Cheers. -Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
