Re: Java2d Benchmarking results
It seems like something like this may be relatively simple to try with our gtk port as well. Enumerate each native method and, instead of calling the native methods directly, simply write the function enumeration and parameter values to a queue of sorts. The native command processor would be pretty simple to write. I think it would be simple at a first look, however to write a good performing implementation (which is the goal of all this imho) is another story. Just choosing a NIO-Buffer which does not need to do any conversation oif the platform has the "needed" endianess brought a large performance boost to Sun's implementation. However sounds pretty interresting ... lg Clemens
Generics Branch Merge Announcement (2006/06/27)
Hi all, HEAD is again merged to generics; relevant dates are 2006/06/16 to 2006/06/27. Keep up the good work, -- Andrew :) Department of Computer Science University of Sheffield signature.asc Description: This is a digitally signed message part
Re: diffie-hellman problem
hello Christian, On Tuesday 27 June 2006 19:45, Christian Thalinger wrote: > On Tue, 2006-06-27 at 19:35 +1000, Raif S. Naffah wrote: > > i'll have a closer look at it and will let you know. > > > > btw. i presume you're using the CVS HEAD? > > Yes, right. found the problem; should be able to check-in a fix within the next 48h. cheers; rsn pgputn5RaoAwe.pgp Description: PGP signature
Re: diffie-hellman problem
On Tue, 2006-06-27 at 19:35 +1000, Raif S. Naffah wrote: > i'll have a closer look at it and will let you know. > > btw. i presume you're using the CVS HEAD? Yes, right. TWISTI
Re: diffie-hellman problem
hello Christian, On Tuesday 27 June 2006 08:25, Christian Thalinger wrote: > Hi! > > I'm trying to run an application which uses a lot of crypto stuff and > I ran into some problems. A friend of mine told me to try some > tests, like this one: > > http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.ht >ml#DH2Ex > > And actually it does not work with GNU Classpath. I get: > > $ cacao DHKeyAgreement2 > Using SKIP Diffie-Hellman parameters > ALICE: Generate DH keypair ... > ALICE: Initialization ... > java.security.spec.InvalidKeySpecException >at > gnu.javax.crypto.jce.sig.DHKeyFactory.engineGeneratePublic(DHKeyFacto >ry.java:94) at > java.security.KeyFactory.generatePublic(KeyFactory.java:219) at > DHKeyAgreement2.run(DHKeyAgreement2.java:107) >at DHKeyAgreement2.main(DHKeyAgreement2.java:54) > Caused by: java.lang.NumberFormatException >at java.math.BigInteger.(BigInteger.java:156) >at > gnu.java.security.der.DERReader.readUniversal(DERReader.java:226) at > gnu.java.security.der.DERReader.read(DERReader.java:165) at > gnu.javax.crypto.key.dh.DHKeyPairX509Codec.decodePublicKey(DHKeyPairX >509Codec.java:212) at > gnu.javax.crypto.jce.sig.DHKeyFactory.engineGeneratePublic(DHKeyFacto >ry.java:89) ...3 more > > Any ideas? i'll have a closer look at it and will let you know. btw. i presume you're using the CVS HEAD? cheers; rsn pgpjO8ie433kb.pgp Description: PGP signature
Re: Java2d Benchmarking results
Hi folks, Am Montag, den 26.06.2006, 16:50 -0400 schrieb Francis Kung: > Further to this thread, I've tested each image operation against the > baseline case, and posted the results at http://fkung.wordpress.com/ Interesting! > All operations on fill(Rectangle2D) also seem very expensive compared to > the rest. I suppose this (at least partially) comes from the JNI overhead here: we transfer the Shape to the native code making 1 JNI call per point/control-point and a couple more to actually paint it. This is very ineffcient, given that (plain) polygon/shape filling is a rather cheap operation. I currently start working on a GL based Graphics2D impl, on top of Escher, which (afaics) has the potential to be very efficient, simply because it avoids JNI calls altogether (except to java.net code every now and then). This could be even more efficient than Sun does (they push 'graphics commands' to a queue, which is read by a native thread that translates it to native GL calls, which - in the case of X - are pushing commands to a queue again... if I understand that correctly). Cheers, Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
diffie-hellman problem
Hi! I'm trying to run an application which uses a lot of crypto stuff and I ran into some problems. A friend of mine told me to try some tests, like this one: http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html#DH2Ex And actually it does not work with GNU Classpath. I get: $ cacao DHKeyAgreement2 Using SKIP Diffie-Hellman parameters ALICE: Generate DH keypair ... ALICE: Initialization ... java.security.spec.InvalidKeySpecException at gnu.javax.crypto.jce.sig.DHKeyFactory.engineGeneratePublic(DHKeyFactory.java:94) at java.security.KeyFactory.generatePublic(KeyFactory.java:219) at DHKeyAgreement2.run(DHKeyAgreement2.java:107) at DHKeyAgreement2.main(DHKeyAgreement2.java:54) Caused by: java.lang.NumberFormatException at java.math.BigInteger.(BigInteger.java:156) at gnu.java.security.der.DERReader.readUniversal(DERReader.java:226) at gnu.java.security.der.DERReader.read(DERReader.java:165) at gnu.javax.crypto.key.dh.DHKeyPairX509Codec.decodePublicKey(DHKeyPairX509Codec.java:212) at gnu.javax.crypto.jce.sig.DHKeyFactory.engineGeneratePublic(DHKeyFactory.java:89) ...3 more Any ideas? TWISTI
