From roman at kennke.org Tue May 8 21:58:05 2007 From: roman at kennke.org (Roman Kennke) Date: Tue, 08 May 2007 23:58:05 +0200 Subject: DataBuffer, ColorModels and SampleModels Message-ID: <1178661485.26796.7.camel@localhost> Hi there, I just downloaded the freshly released OpenJDK sourcecode (thanks alot for that!). I'm glancing around the code right now. It's appearing to me that in java.awt.image there are a couple of pieces missing, that is the DataBuffer, ColorModel and SampleModel classes and subclasses. I wonder if that is already beeing worked on and (close to) ready to go in? I haven't heard so far that this was one of the encumbered areas. If that is not the case, I could offer to 1. try out the GNU Classpath versions of these classes, a couple of which I implemented myself, and/or 2. Reimplement them from scratch with the GNU Classpath versions in mind, plus using the existing test suites. These classes are not overly complex and could be a good starting point for me to get my hands dirty, especially since I'm currently having my nose in those classes anyway as part of my own project. What do you think? Cheers, Roman -- http://kennke.org/blog/ From roman at kennke.org Tue May 8 22:05:13 2007 From: roman at kennke.org (Roman Kennke) Date: Wed, 09 May 2007 00:05:13 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178661485.26796.7.camel@localhost> References: <1178661485.26796.7.camel@localhost> Message-ID: <1178661913.26796.10.camel@localhost> Again, > I'm glancing around the code right now. It's appearing to me that in > java.awt.image there are a couple of pieces missing, that is the > DataBuffer, ColorModel and SampleModel classes and subclasses. Uhm sorry, small mistake here. The ColorModel classes are apparently already there, as well as 1 SampleModel and 2 (quite exotic) DataBuffer class. /Roman -- http://kennke.org/blog/ From Phil.Race at Sun.COM Wed May 9 00:56:43 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 08 May 2007 17:56:43 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178661913.26796.10.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> Message-ID: <46411C4B.3060001@sun.com> There are a number of classes in java.awt.image, java.awt.image.renderable, and java.awt.color that are in many cases, mostly Sun code but have some 3rd party content. We can distentangle this so its not an encumbrance per se as an entire module/lib might be which is the case with the others. And we don't particularly want to do the disentanglement if we hear back that in fact its OK ..and we have a reasonable expectation that is what will happen. But also we couldn't really hold up JavaOne for this :). So they are left out deliberately for now and provided as 'binary' plugs. BTW we (2D etc) are pretty much "out" at JavaOne this week. -Phil. Roman Kennke wrote: > Again, > > >> I'm glancing around the code right now. It's appearing to me that in >> java.awt.image there are a couple of pieces missing, that is the >> DataBuffer, ColorModel and SampleModel classes and subclasses. >> > > Uhm sorry, small mistake here. The ColorModel classes are apparently > already there, as well as 1 SampleModel and 2 (quite exotic) DataBuffer > class. > > /Roman > > From roman at kennke.org Wed May 9 07:10:14 2007 From: roman at kennke.org (Roman Kennke) Date: Wed, 09 May 2007 09:10:14 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <46411C4B.3060001@sun.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> Message-ID: <1178694614.7957.2.camel@localhost> Hi, Am Dienstag, den 08.05.2007, 17:56 -0700 schrieb Phil Race: > There are a number of classes in java.awt.image, > java.awt.image.renderable, and java.awt.color > that are in many cases, mostly Sun code but have some 3rd party content. > We can distentangle this so its not an encumbrance per se as an entire > module/lib > might be which is the case with the others. And we don't particularly > want to do the > disentanglement if we hear back that in fact its OK ..and we have a > reasonable > expectation that is what will happen. But also we couldn't really hold up > JavaOne for this :). So they are left out deliberately for now and > provided as > 'binary' plugs. Thanks alot for the explanation Phil. I'll study the available code then and see what could possibly be done about the CMS problems. One quick question: The build seems to always pull in the encumbered classes from the plug, even if I put in a replacement class in the main tree. Is there an easy way (like a list of classes) to disable pulling in certain classes? I can't seem to quickly find such a list or something. > BTW we (2D etc) are pretty much "out" at JavaOne this week. Yeah! I actually was wondering if anybody's already listening on this list ;-) Have fun! Cheers, Roman -- http://kennke.org/blog/ From Phil.Race at Sun.COM Wed May 9 07:16:12 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 00:16:12 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178694614.7957.2.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> Message-ID: <4641753C.8010900@sun.com> Roman Kennke wrote: > Thanks alot for the explanation Phil. I'll study the available code then > and see what could possibly be done about the CMS problems. you mean the littlecms code right? that's separate from these classes. > One quick > question: The build seems to always pull in the encumbered classes from > the plug, even if I put in a replacement class in the main tree. Is > there an easy way (like a list of classes) to disable pulling in certain > classes? I can't seem to quickly find such a list or something. > > > In order to know which classes to pull in and no others they have too enumerated so all you need to do is find where they are enumerated and remove references to the specific classes look in make/java/redist/Makefile and make/java/awt/Makefile -phil. From Dmitri.Trembovetski at Sun.COM Wed May 9 07:21:34 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 09 May 2007 00:21:34 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178694614.7957.2.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> Message-ID: <4641767E.9010708@Sun.COM> Hi Roman, Roman Kennke wrote: > Hi, > > Am Dienstag, den 08.05.2007, 17:56 -0700 schrieb Phil Race: >> There are a number of classes in java.awt.image, >> java.awt.image.renderable, and java.awt.color >> that are in many cases, mostly Sun code but have some 3rd party content. >> We can distentangle this so its not an encumbrance per se as an entire >> module/lib >> might be which is the case with the others. And we don't particularly >> want to do the >> disentanglement if we hear back that in fact its OK ..and we have a >> reasonable >> expectation that is what will happen. But also we couldn't really hold up >> JavaOne for this :). So they are left out deliberately for now and >> provided as >> 'binary' plugs. > > Thanks alot for the explanation Phil. I'll study the available code then > and see what could possibly be done about the CMS problems. One quick > question: The build seems to always pull in the encumbered classes from > the plug, even if I put in a replacement class in the main tree. Is > there an easy way (like a list of classes) to disable pulling in certain > classes? I can't seem to quickly find such a list or something. > Yeah, you should find it in the appropriate makefiles - make/java/redist/Makefile // this one lists all encumbered classes make/java/awt/Makefile // lists closed classes in java.awt.* packages make/sun/font/Makefile // font rasterizer-related stuff make/sun/cmm // ? not sure about the name, don't have the workspace here The way the build currently works is that there's a target in each of those makefiles which extracts the binary stuff from the plugs related to the files built from a particular directory. The one in make/java/redist/Makefile extracts all of them (it's run once when you build the ws from scratch) and then you can just rebuild from make/java/awt if you added some classes to java/awt/ packages. Thanks, Dmitri >> BTW we (2D etc) are pretty much "out" at JavaOne this week. > > Yeah! I actually was wondering if anybody's already listening on this > list ;-) Have fun! > > Cheers, Roman From roman at kennke.org Wed May 9 07:41:00 2007 From: roman at kennke.org (Roman Kennke) Date: Wed, 09 May 2007 09:41:00 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <4641753C.8010900@sun.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> Message-ID: <1178696460.7957.7.camel@localhost> Am Mittwoch, den 09.05.2007, 00:16 -0700 schrieb Phil Race: > Roman Kennke wrote: > > Thanks alot for the explanation Phil. I'll study the available code then > > and see what could possibly be done about the CMS problems. > you mean the littlecms code right? that's separate from these classes. Yeah, littlecms and java.awt.color in general. And most importantly the test classes. Is the new code that glues in littlecms available somehow? > look in make/java/redist/Makefile and make/java/awt/Makefile Thanks! /Roman -- http://kennke.org/blog/ From roman at kennke.org Wed May 9 11:41:32 2007 From: roman at kennke.org (Roman Kennke) Date: Wed, 09 May 2007 13:41:32 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <4641753C.8010900@sun.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> Message-ID: <1178710892.7957.41.camel@localhost> Hi again, Am Mittwoch, den 09.05.2007, 00:16 -0700 schrieb Phil Race: > Roman Kennke wrote: > > Thanks alot for the explanation Phil. I'll study the available code then > > and see what could possibly be done about the CMS problems. > you mean the littlecms code right? that's separate from these classes. As mentioned here: http://kennke.org/blog/2007/05/09/color-encumbrance-fixed/ I've been able to build OpenJDK with GNU Classpath's color management classes. This was really a no-brainer and seems to work fine from my POV. It also fixes the GRAY->sRGB problem. The other two I couldn't easily test due to lack of testcases. Also, the OpenJDK code doesn't seem to ship with testcases for the color package in general, so I couldn't test the new classes at all (besides some simple programs I wrote myself and the Mauve suite). Are there any regression or other tests available for this? I don't know if this implementation is feasible for inclusion in OpenJDK. The code is copyrighted by the FSF and is licensed under the same license as OpenJDK. It's an open source project just as littleCMS or whatnot. Technically, I think it's attractive because it's a Java implementation and thus much easier to handle and portable than littleCMS. If you'd like to test this, the above linked page has a link to a small ZIP file containing the related classes. /Roman -- http://kennke.org/blog/ From Phil.Race at Sun.COM Wed May 9 14:03:51 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 07:03:51 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178696460.7957.7.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178696460.7957.7.camel@localhost> Message-ID: <4641D4C7.8080108@sun.com> Roman Kennke wrote: > Yeah, littlecms and java.awt.color in general. And most importantly the > test classes. Is the new code that glues in littlecms available somehow? > src/share/classes/sun/java2d/cmm/ defines the pluggable API that accepts either Kodak CMS or LittleCMS -phil From Phil.Race at Sun.COM Wed May 9 14:37:31 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 07:37:31 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178710892.7957.41.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> Message-ID: <4641DCAB.8060704@sun.com> Tests fall into categories of JCK/TCK - supposedly to be available for openjdk builds although I haven't kept up with the intricacies of this Regression tests - these are in the JDK under test but we are required to vet them almost one by one to verify their provenance and this is onerous. So most are not there yet. SQE developed tests - no idea what the plan is Performance - J2Dbench2 may have some color tests but I don't remember seeing any ... but they can be added Demos : Java2Demo. Not in openjdk yet but you can run the one from the binary build So you should at least test the images and color tabs of the 2D demo and see if J2DBench has any tests that make it worth running. Performance matters. As for licensing as I understand it it has to come in to the openjdk code base via a SCA as we build the 'commercially' licensed one from the same code base. -phil. Roman Kennke wrote: > Hi again, > > Am Mittwoch, den 09.05.2007, 00:16 -0700 schrieb Phil Race: > >> Roman Kennke wrote: >> >>> Thanks alot for the explanation Phil. I'll study the available code then >>> and see what could possibly be done about the CMS problems. >>> >> you mean the littlecms code right? that's separate from these classes. >> > > As mentioned here: > http://kennke.org/blog/2007/05/09/color-encumbrance-fixed/ > > I've been able to build OpenJDK with GNU Classpath's color management > classes. This was really a no-brainer and seems to work fine from my > POV. It also fixes the GRAY->sRGB problem. The other two I couldn't > easily test due to lack of testcases. Also, the OpenJDK code doesn't > seem to ship with testcases for the color package in general, so I > couldn't test the new classes at all (besides some simple programs I > wrote myself and the Mauve suite). Are there any regression or other > tests available for this? > > I don't know if this implementation is feasible for inclusion in > OpenJDK. The code is copyrighted by the FSF and is licensed under the > same license as OpenJDK. It's an open source project just as littleCMS > or whatnot. Technically, I think it's attractive because it's a Java > implementation and thus much easier to handle and portable than > littleCMS. If you'd like to test this, the above linked page has a link > to a small ZIP file containing the related classes. > > /Roman > From David.Herron at Sun.COM Wed May 9 15:18:47 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 09 May 2007 08:18:47 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <4641DCAB.8060704@sun.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4641DCAB.8060704@sun.com> Message-ID: <4641E657.3090101@sun.com> There is a more complete listing of testing methodologies the Java SE team uses here: http://openjdk.java.net/groups/quality/methodologies.html The SQE team (which I represent) is still in the planning for what tests we're going to release. One thing we want to do is work together with the public to build new tests because I think there's a lot of information held in the minds of application developers about the real quality issues y'all are facing, that information is not known to us, so it would be most productive to work together to turn that information into tests. - David Herron Phil Race wrote: > Tests fall into categories of > JCK/TCK - supposedly to be available for openjdk builds although I > haven't kept up with the intricacies of this > Regression tests - these are in the JDK under test but we are required > to vet them almost one by one to verify their provenance > and this is onerous. So most are not there yet. > SQE developed tests - no idea what the plan is > Performance - J2Dbench2 may have some color tests but I don't remember > seeing any ... but they can be added > Demos : Java2Demo. Not in openjdk yet but you can run the one from > the binary build > > So you should at least test the images and color tabs of the 2D demo > and see if J2DBench has > any tests that make it worth running. Performance matters. > > As for licensing as I understand it it has to come in to the openjdk > code base via a SCA > as we build the 'commercially' licensed one from the same code base. > > -phil. > > > Roman Kennke wrote: >> Hi again, >> >> Am Mittwoch, den 09.05.2007, 00:16 -0700 schrieb Phil Race: >> >>> Roman Kennke wrote: >>> >>>> Thanks alot for the explanation Phil. I'll study the available code >>>> then >>>> and see what could possibly be done about the CMS problems. >>>> >>> you mean the littlecms code right? that's separate from these classes. >>> >> >> As mentioned here: >> http://kennke.org/blog/2007/05/09/color-encumbrance-fixed/ >> >> I've been able to build OpenJDK with GNU Classpath's color management >> classes. This was really a no-brainer and seems to work fine from my >> POV. It also fixes the GRAY->sRGB problem. The other two I couldn't >> easily test due to lack of testcases. Also, the OpenJDK code doesn't >> seem to ship with testcases for the color package in general, so I >> couldn't test the new classes at all (besides some simple programs I >> wrote myself and the Mauve suite). Are there any regression or other >> tests available for this? >> >> I don't know if this implementation is feasible for inclusion in >> OpenJDK. The code is copyrighted by the FSF and is licensed under the >> same license as OpenJDK. It's an open source project just as littleCMS >> or whatnot. Technically, I think it's attractive because it's a Java >> implementation and thus much easier to handle and portable than >> littleCMS. If you'd like to test this, the above linked page has a link >> to a small ZIP file containing the related classes. >> >> /Roman >> > From roman at kennke.org Wed May 9 15:56:51 2007 From: roman at kennke.org (Roman Kennke) Date: Wed, 09 May 2007 17:56:51 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <4641DCAB.8060704@sun.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4641DCAB.8060704@sun.com> Message-ID: <1178726211.7957.51.camel@localhost> Hi Phil, > Tests fall into categories of > JCK/TCK - supposedly to be available for openjdk builds although I > haven't kept up with the intricacies of this > Regression tests - these are in the JDK under test but we are required > to vet them almost one by one to verify their provenance > and this is onerous. So most are not there yet. > SQE developed tests - no idea what the plan is > Performance - J2Dbench2 may have some color tests but I don't remember > seeing any ... but they can be added > Demos : Java2Demo. Not in openjdk yet but you can run the one from the > binary build > > So you should at least test the images and color tabs of the 2D demo > and see if J2DBench has > any tests that make it worth running. Performance matters. Ok, I'll test the Java2Demo and J2DBench. > As for licensing as I understand it it has to come in to the openjdk > code base via a SCA > as we build the 'commercially' licensed one from the same code base. What about littleCMS (or any other external open source library for that matter)? Are the copyright holders of these also required to sign the SCA? /Roman -- http://kennke.org/blog/ From roman at kennke.org Wed May 9 16:02:40 2007 From: roman at kennke.org (Roman Kennke) Date: Wed, 09 May 2007 18:02:40 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <4641D4C7.8080108@sun.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178696460.7957.7.camel@localhost> <4641D4C7.8080108@sun.com> Message-ID: <1178726560.7957.55.camel@localhost> > src/share/classes/sun/java2d/cmm/ defines the pluggable API > > that accepts either Kodak CMS or LittleCMS Oh interesting. The GNU Classpath API is directly implemented in the java.awt.color and gnu.java.awt.color without some plugging in between. The pluggable API doesn't seem to easily fit. Too bad. It seems that some pieces in java.awt.image are dependend on that pluggable API (rather than using java.awt.color directly) so this probably is not as easy as I hoped. /Roman -- http://kennke.org/blog/ From Phil.Race at Sun.COM Wed May 9 16:03:56 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 09:03:56 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178726211.7957.51.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4641DCAB.8060704@sun.com> <1178726211.7957.51.camel@localhost> Message-ID: <4641F0EC.20708@sun.com> When code like that or X11 headers etc etc are used in the JDK we have to have a legal review. If they say yes, we can use it , if they say no, we can't. BSD and X11 style licenses are generally OK, but in each case it requires a specific legal review. Basically the SCA short circuits all that (I think) , basically because its the author saying I wrote this code so I have rights to donate it .. -phil. > What about littleCMS (or any other external open source library for that > matter)? Are the copyright holders of these also required to sign the > SCA? > > > > From Dmitri.Trembovetski at Sun.COM Thu May 10 05:37:18 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 09 May 2007 22:37:18 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1178710892.7957.41.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> Message-ID: <4642AF8E.70100@Sun.COM> Hi Roman, that's pretty impressive! Regarding the tests - I believe Alexey wrote some additional regression tests when working with littlecms code (including some multi-threaded tests). I don't think they're in the opened regression tests directory yet, but that we should be able to easily fix (we just need to update some headers and move them around). Thanks, Dmitri Roman Kennke wrote: > Hi again, > > Am Mittwoch, den 09.05.2007, 00:16 -0700 schrieb Phil Race: >> Roman Kennke wrote: >>> Thanks alot for the explanation Phil. I'll study the available code then >>> and see what could possibly be done about the CMS problems. >> you mean the littlecms code right? that's separate from these classes. > > As mentioned here: > http://kennke.org/blog/2007/05/09/color-encumbrance-fixed/ > > I've been able to build OpenJDK with GNU Classpath's color management > classes. This was really a no-brainer and seems to work fine from my > POV. It also fixes the GRAY->sRGB problem. The other two I couldn't > easily test due to lack of testcases. Also, the OpenJDK code doesn't > seem to ship with testcases for the color package in general, so I > couldn't test the new classes at all (besides some simple programs I > wrote myself and the Mauve suite). Are there any regression or other > tests available for this? > > I don't know if this implementation is feasible for inclusion in > OpenJDK. The code is copyrighted by the FSF and is licensed under the > same license as OpenJDK. It's an open source project just as littleCMS > or whatnot. Technically, I think it's attractive because it's a Java > implementation and thus much easier to handle and portable than > littleCMS. If you'd like to test this, the above linked page has a link > to a small ZIP file containing the related classes. > > /Roman From roman at kennke.org Sun May 13 21:07:09 2007 From: roman at kennke.org (Roman Kennke) Date: Sun, 13 May 2007 23:07:09 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <4642AF8E.70100@Sun.COM> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4642AF8E.70100@Sun.COM> Message-ID: <1179090430.10654.6.camel@localhost> Hi there, > that's pretty impressive! Yeah, and the performance is even more impressive. I've done a small test which converts 1000000 pixels from GRAY to sRGB. This is the performance with the plain OpenJDK (littlecms I suppose? Or even the old Kodak code.): roman at moonlight:~/src/test$ ~/src/openjdk/control/build/linux-i586/bin/java ColorTest converion time for 1000000 pixels: 13050 roman at moonlight:~/src/test$ ~/src/openjdk/control/build/linux-i586/bin/java ColorTest converion time for 1000000 pixels: 406 Find the test attached (It's derived from the gray->srgb testcase that I found in on of the bugreports). I know it's very simplistic and such, but it gives a clue about the performance difference. I suppose it's the 100% Java approach that makes the difference here. Calling some JNI function 1000000 times is much worse than doing all this in Java I suppose. I would really like to run (or have one of you run) this against a conformance testsuite and see how it performs there. AFAIK, Sun and the FSF are talking about how to make code flowing between GNU Classpath and OpenJDK easy/easier. /Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ColorTest.java Type: text/x-java Size: 925 bytes Desc: not available URL: From Jeannette.Hung at Sun.COM Mon May 14 05:15:49 2007 From: Jeannette.Hung at Sun.COM (Jeannette Hung) Date: Sun, 13 May 2007 22:15:49 -0700 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1179090430.10654.6.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4642AF8E.70100@Sun.COM> <1179090430.10654.6.camel@localhost> Message-ID: <4647F085.5010000@sun.com> Wow... That's a huge difference. Did you compare the pixel values between your build, the openjdk build, and the production JRE build? I know the color code isn't straightforward for conversion between a gray and a sRGB color space since I think the gray space is linear and the sRGB one is not. Thanks jeannette Roman Kennke wrote: > Hi there, > >> that's pretty impressive! > > Yeah, and the performance is even more impressive. I've done a small > test which converts 1000000 pixels from GRAY to sRGB. This is the > performance with the plain OpenJDK (littlecms I suppose? Or even the old > Kodak code.): > > roman at moonlight:~/src/test$ > ~/src/openjdk/control/build/linux-i586/bin/java ColorTest > converion time for 1000000 pixels: 13050 > > > roman at moonlight:~/src/test$ > ~/src/openjdk/control/build/linux-i586/bin/java ColorTest > converion time for 1000000 pixels: 406 > > > Find the test attached (It's derived from the gray->srgb testcase that I > found in on of the bugreports). I know it's very simplistic and such, > but it gives a clue about the performance difference. I suppose it's the > 100% Java approach that makes the difference here. Calling some JNI > function 1000000 times is much worse than doing all this in Java I > suppose. > > I would really like to run (or have one of you run) this against a > conformance testsuite and see how it performs there. > > AFAIK, Sun and the FSF are talking about how to make code flowing > between GNU Classpath and OpenJDK easy/easier. > > /Roman > > > > ------------------------------------------------------------------------ > > import java.awt.color.ColorSpace; > > public class ColorTest { > private static final int NUM_COLS = 1000000; > > public static void main(String [] args) { > // Fill pixel array with random data. > int [] cols = new int[NUM_COLS]; > int [] outcols = new int[NUM_COLS * 3]; > for (int i = 0; i < NUM_COLS; i++) { > cols[i] = (int) (Math.random() * 256); > } > > ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_GRAY); > float [] p = new float[1]; > int outIndex = 0; > long start = System.currentTimeMillis(); > for (int i = 0; i < cols.length; i++) { > p[0] = cols[i]/255.0f; > float [] r = cs.toRGB(p); > for (int j = 0; j < r.length; j++) { > outcols[outIndex++] = (int)(r[j]*255); > } > } > System.err.println("conversion time for " + NUM_COLS + " pixels: " + (System.currentTimeMillis() - start)); > } > } From roman at kennke.org Mon May 14 12:15:36 2007 From: roman at kennke.org (Roman Kennke) Date: Mon, 14 May 2007 14:15:36 +0200 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <4647F085.5010000@sun.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4642AF8E.70100@Sun.COM> <1179090430.10654.6.camel@localhost> <4647F085.5010000@sun.com> Message-ID: <1179144936.5678.19.camel@localhost> Hi, > Wow... That's a huge difference. Did you compare the pixel values > between your build, the openjdk build, and the production JRE build? I did so just now. I bombed the standard jdk6 build with 1000000 random values and stored the conversion results in a file. Another program reads in those values and compares it with the same conversion on the current VM's build. Here are the results: plain OpenJDK: average difference from reference: 0.00380017 maximum difference from reference: 0.038417127 OpenJDK with Classpath CMS: average difference from reference: 0.00280433 maximum difference from reference: 0.0042832294 > I > know the color code isn't straightforward for conversion between a gray > and a sRGB color space since I think the gray space is linear and the > sRGB one is not. Yeah right. And apparently the code needs more testing for other conversions than gray->rgb. /Roman -- http://kennke.org/blog/ From Ben.LOUD at baesystems.com Mon May 14 16:50:20 2007 From: Ben.LOUD at baesystems.com (LOUD, Ben) Date: Tue, 15 May 2007 02:20:20 +0930 Subject: DataBuffer, ColorModels and SampleModels References: <1178661485.26796.7.camel@localhost><1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com><1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com><1178710892.7957.41.camel@localhost> <4642AF8E.70100@Sun.COM><1179090430.10654.6.camel@localhost> <4647F085.5010000@sun.com> <1179144936.5678.19.camel@localhost> Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A012CAE9B@SBEMAIL1.au.baesystems.com> I thought I'd give it a go as I was curious to if your performance claims were true. I compared Classpath vs JDK6 RI, and sure enough, the performance of the Classpath implementation was indeed hundreds of times faster. It's much too significant to be JNI overhead. So I had a look at the Classpath code, the implementation in GrayScaleConverter is trivial, just a couple of lines, (no need to use tone reproduction curves or matrices at all) Comparing it to equations (1.2a) and (1.2b) in the w3c sRGB spec (http://www.w3.org/Graphics/Color/sRGB), it would seem to be correct. I modified it slightly so that the conversion expression was done using all doubles and used StrichMath.pow, but still results were consistently only accurate with JDK6 to around 2 decimal places (I'd argue thats a very significant error for double precision math). I tested conversions between various combinations of color spaces and there were differences every time, and given that the JDK6 version takes hundreds of times longer, it must be doing something far more complex than these trivial equations. An interesting note: float[] xyz = { x, y, z }; ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_CIEXYZ); float[] xyz2 = cs.toCIEXYZ(xyz); With the Classpath implementation, this returns a result array with values elements identical to the original array. (as expected, it just does System.arraycopy). But with JDK6, the resulting elements are slightly different. Same with CS_sRGB and toRGB(). Is it possible JDK6's color library is slightly innaccurate? Still, even if we take the JDK6 version as "accurate", the Classpath version doesnt seem to be any less accurate than little cms (in fact, from Romans test, it's actually closer on average) Still, to be sure it would need to be tested with ICC profiles read from disc. One last thing, if the java.awt.color was to be replaced with an all-Java version, wouldnt the native graphics system depend on the native color library? I'd expect there'd be issues there. ________________________________ From: 2d-dev-bounces at openjdk.java.net on behalf of Roman Kennke Sent: Mon 14/05/2007 9:45 PM To: Jeannette.Hung at sun.com Cc: 2d-dev; Phil Race; Dmitri Trembovetski; Alexey Ushakov Subject: Re: DataBuffer, ColorModels and SampleModels Hi, > Wow... That's a huge difference. Did you compare the pixel values > between your build, the openjdk build, and the production JRE build? I did so just now. I bombed the standard jdk6 build with 1000000 random values and stored the conversion results in a file. Another program reads in those values and compares it with the same conversion on the current VM's build. Here are the results: plain OpenJDK: average difference from reference: 0.00380017 maximum difference from reference: 0.038417127 OpenJDK with Classpath CMS: average difference from reference: 0.00280433 maximum difference from reference: 0.0042832294 > I > know the color code isn't straightforward for conversion between a gray > and a sRGB color space since I think the gray space is linear and the > sRGB one is not. Yeah right. And apparently the code needs more testing for other conversions than gray->rgb. /Roman -- http://kennke.org/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexey.Ushakov at Sun.COM Mon May 14 22:09:35 2007 From: Alexey.Ushakov at Sun.COM (Alexey Ushakov) Date: Tue, 15 May 2007 02:09:35 +0400 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <1179090430.10654.6.camel@localhost> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4642AF8E.70100@Sun.COM> <1179090430.10654.6.camel@localhost> Message-ID: <4648DE1F.8060805@Sun.COM> Hello Roman, You are right concerning JNI overhead that we have when using native library for per-pixel conversion. But actually it's not a case for most user applications working with color conversion stuff. The most common usage is color conversion for the whole image. In this case for most common formats of the images (like sRGB, USHORT_GRAY, BYTE_GRAY) conversion is performed for whole image at once. So, JNI overhead is not sufficient here. Could you please try out image test (attached) with your builds, so we can figure out what's happening in most usual case. Best Regards, Alexey Roman Kennke wrote On 14.05.2007 01:07,: >Hi there, > > > >> that's pretty impressive! >> >> > >Yeah, and the performance is even more impressive. I've done a small >test which converts 1000000 pixels from GRAY to sRGB. This is the >performance with the plain OpenJDK (littlecms I suppose? Or even the old >Kodak code.): > >roman at moonlight:~/src/test$ >~/src/openjdk/control/build/linux-i586/bin/java ColorTest >converion time for 1000000 pixels: 13050 > > >roman at moonlight:~/src/test$ >~/src/openjdk/control/build/linux-i586/bin/java ColorTest >converion time for 1000000 pixels: 406 > > >Find the test attached (It's derived from the gray->srgb testcase that I >found in on of the bugreports). I know it's very simplistic and such, >but it gives a clue about the performance difference. I suppose it's the >100% Java approach that makes the difference here. Calling some JNI >function 1000000 times is much worse than doing all this in Java I >suppose. > >I would really like to run (or have one of you run) this against a >conformance testsuite and see how it performs there. > >AFAIK, Sun and the FSF are talking about how to make code flowing >between GNU Classpath and OpenJDK easy/easier. > >/Roman > > > >------------------------------------------------------------------------ > >import java.awt.color.ColorSpace; > >public class ColorTest { > private static final int NUM_COLS = 1000000; > > public static void main(String [] args) { > // Fill pixel array with random data. > int [] cols = new int[NUM_COLS]; > int [] outcols = new int[NUM_COLS * 3]; > for (int i = 0; i < NUM_COLS; i++) { > cols[i] = (int) (Math.random() * 256); > } > > ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_GRAY); > float [] p = new float[1]; > int outIndex = 0; > long start = System.currentTimeMillis(); > for (int i = 0; i < cols.length; i++) { > p[0] = cols[i]/255.0f; > float [] r = cs.toRGB(p); > for (int j = 0; j < r.length; j++) { > outcols[outIndex++] = (int)(r[j]*255); > } > } > System.err.println("conversion time for " + NUM_COLS + " pixels: " + (System.currentTimeMillis() - start)); > } >} > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ImageTest.java Type: text/x-java Size: 792 bytes Desc: not available URL: From Ben.LOUD at baesystems.com Tue May 15 00:20:10 2007 From: Ben.LOUD at baesystems.com (LOUD, Ben) Date: Tue, 15 May 2007 09:50:10 +0930 Subject: DataBuffer, ColorModels and SampleModels Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A012D0688@SBEMAIL1.au.baesystems.com> Ah, I just read the ICC_ColorSpace JavaDocs more closely (always helps), and of course, they say that toRGB uses a perceptual conversion (which is good). The Classpath converters just do a trivial relative colorimetric conversions (which are defined in the w3c spec) where the results are very accurate provided the colors are within gamut. Any out of gamut colors just get clipped (bad, information is lost). Libraries like Kodak are a bit more intelligent and compress the gamut, so out of gamut colors can still be converted with some level of accuracy, but it means there'll be slight innaccuracies for in gamut colors (though the overall perceptual quality is improved). The down side is there's no "correct" way to do this, the results will be different with each CMM. With that in mind, I don't think the Classpath code is suitable -----Original Message----- From: 2d-dev-bounces at openjdk.java.net [mailto:2d-dev-bounces at openjdk.java.net] On Behalf Of Roman Kennke Sent: Monday, 14 May 2007 9:46 PM To: Jeannette.Hung at sun.com Cc: 2d-dev; Phil Race; Dmitri Trembovetski; Alexey Ushakov Subject: Re: DataBuffer, ColorModels and SampleModels Hi, > Wow... That's a huge difference. Did you compare the pixel values > between your build, the openjdk build, and the production JRE build? I did so just now. I bombed the standard jdk6 build with 1000000 random values and stored the conversion results in a file. Another program reads in those values and compares it with the same conversion on the current VM's build. Here are the results: plain OpenJDK: average difference from reference: 0.00380017 maximum difference from reference: 0.038417127 OpenJDK with Classpath CMS: average difference from reference: 0.00280433 maximum difference from reference: 0.0042832294 > I > know the color code isn't straightforward for conversion between a gray > and a sRGB color space since I think the gray space is linear and the > sRGB one is not. Yeah right. And apparently the code needs more testing for other conversions than gray->rgb. /Roman -- http://kennke.org/blog/ From Alexey.Ushakov at Sun.COM Tue May 15 00:29:24 2007 From: Alexey.Ushakov at Sun.COM (Alexey Ushakov) Date: Tue, 15 May 2007 04:29:24 +0400 Subject: DataBuffer, ColorModels and SampleModels In-Reply-To: <755F5FA20B29364FBA287DB1BEBCE80A012CAE9B@SBEMAIL1.au.baesystems.com> References: <1178661485.26796.7.camel@localhost> <1178661913.26796.10.camel@localhost> <46411C4B.3060001@sun.com> <1178694614.7957.2.camel@localhost> <4641753C.8010900@sun.com> <1178710892.7957.41.camel@localhost> <4642AF8E.70100@Sun.COM> <1179090430.10654.6.camel@localhost> <4647F085.5010000@sun.com> <1179144936.5678.19.camel@localhost> <755F5FA20B29364FBA287DB1BEBCE80A012CAE9B@SBEMAIL1.au.baesystems.com> Message-ID: <4648FEE4.5050500@Sun.COM> Hello Ben, Please see my answers bellow. LOUD, Ben wrote On 14.05.2007 20:50,: > I thought I'd give it a go as I was curious to if your performance > claims were true. I compared Classpath vs JDK6 RI, and sure enough, > the performance of the Classpath implementation was indeed hundreds of > times faster. It's much too significant to be JNI overhead. > > So I had a look at the Classpath code, the implementation in > GrayScaleConverter is trivial, just a couple of lines, (no need to use > tone reproduction curves or matrices at all) Comparing it to equations > (1.2a) and (1.2b) in the w3c sRGB spec > (http://www.w3.org/Graphics/Color/sRGB), it would seem to be correct. > I modified it slightly so that the conversion expression was done > using all doubles and used StrichMath.pow, but still results were > consistently only accurate with JDK6 to around 2 decimal places (I'd > argue thats a very significant error for double precision math). > > I tested conversions between various combinations of color spaces and > there were differences every time, and given that the JDK6 version > takes hundreds of times longer, it must be doing something far more > complex than these trivial equations. > > An interesting note: > > float[] xyz = { x, y, z }; > ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_CIEXYZ); > float[] xyz2 = cs.toCIEXYZ(xyz); > > With the Classpath implementation, this returns a result array with > values elements identical to the original array. (as expected, it just > does System.arraycopy). But with JDK6, the resulting elements are > slightly different. Same with CS_sRGB and toRGB(). > > Is it possible JDK6's color library is slightly innaccurate? Actually, for performance reason (which is not the case in per-pixel conversions because of JNI overhead). JDK6 proprietary color management and littleCMS uses fixed point math. JDK6 CM and littleCMS has 16 bit precision fixed point calculations (moreover littleCMS for some data formats uses 8-bit fixed point math). So, because of that we have such a difference comparing with using exact formulas with double precision. LittleCMS has double precision codepaths but they are very slow, so cannot be used for image conversions (though might be useful for per-pixel stuff) > > Still, even if we take the JDK6 version as "accurate", the Classpath > version doesnt seem to be any less accurate than little cms (in fact, > from Romans test, it's actually closer on average) Still, to be sure > it would need to be tested with ICC profiles read from disc. > > One last thing, if the java.awt.color was to be replaced with an > all-Java version, wouldnt the native graphics system depend on the > native color library? I'd expect there'd be issues there. Could you please clarify you question. Best Regards, Alexey > > ------------------------------------------------------------------------ > *From:* 2d-dev-bounces at openjdk.java.net on behalf of Roman Kennke > *Sent:* Mon 14/05/2007 9:45 PM > *To:* Jeannette.Hung at sun.com > *Cc:* 2d-dev; Phil Race; Dmitri Trembovetski; Alexey Ushakov > *Subject:* Re: DataBuffer, ColorModels and SampleModels > > Hi, > > > Wow... That's a huge difference. Did you compare the pixel values > > between your build, the openjdk build, and the production JRE build? > > I did so just now. I bombed the standard jdk6 build with 1000000 random > values and stored the conversion results in a file. Another program > reads in those values and compares it with the same conversion on the > current VM's build. Here are the results: > > plain OpenJDK: > average difference from reference: 0.00380017 > maximum difference from reference: 0.038417127 > > OpenJDK with Classpath CMS: > average difference from reference: 0.00280433 > maximum difference from reference: 0.0042832294 > > > I > > know the color code isn't straightforward for conversion between a gray > > and a sRGB color space since I think the gray space is linear and the > > sRGB one is not. > > Yeah right. And apparently the code needs more testing for other > conversions than gray->rgb. > > /Roman > > -- > http://kennke.org/blog/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tom.Marble at Sun.COM Sat May 19 21:01:41 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Sat, 19 May 2007 16:01:41 -0500 Subject: [OpenJDK 2D-Dev] test message Message-ID: <464F65B5.3090905@sun.com> All: Please ignore this test message. --Tom From flameeyes at gmail.com Mon May 21 20:14:42 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Mon, 21 May 2007 22:14:42 +0200 Subject: [OpenJDK 2D-Dev] Fw: [PATCH] Allow linking in (shared) libfontconfig directy Message-ID: <20070521221442.22b07781@enterprise.flameeyes.is-a-geek.org> Forwarding to 2d-dev as asked by Oleg Sukhodolsky (originally from awt-dev). Begin forwarded message: Date: Mon, 21 May 2007 17:45:29 +0200 From: Diego 'Flameeyes' Petten? To: awt-dev at openjdk.java.net Subject: [PATCH] Allow linking in (shared) libfontconfig directy As it is, OpenJDK tries to dlopen fontconfig (multiple times too), to avoid a direct link dependency over it. This could be quite slow as the dynamic linker has to do its job multiple times, but is understandable for redistributable packages. Distributions, though, might want to just depend on fontconfig itself and link it directly. The attached patch allows that through the DIRECT_LINK_FONTCONFIG=true option at make. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-fontconfig-directlink.patch.patch Type: text/x-patch Size: 6267 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Phil.Race at Sun.COM Mon May 21 20:18:15 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 21 May 2007 13:18:15 -0700 Subject: [OpenJDK 2D-Dev] Fw: [PATCH] Allow linking in (shared) libfontconfig directy In-Reply-To: <20070521221442.22b07781@enterprise.flameeyes.is-a-geek.org> References: <20070521221442.22b07781@enterprise.flameeyes.is-a-geek.org> Message-ID: <4651FE87.70704@sun.com> Hi, In many apps, fontconfig isn't loaded at all, so explicit linking is actually a loss in startup and footprint. Also since we dlclose, we reclaim the virtual memory, rather than keeping it around when it will never be used again. That is there is a very small bounded set of times when we might load this lib, so its not something we keep coming back to. I also think a couple of the cases could be collapsed into one. One of them was something added last in JDK 6 so it was playing safe rather than disturbing existing code. Perhaps the most common case is going to be when running a GTK Look and Feel app, and we look up the desktop fonts, but in that case Swing pulls in GTK anyway and keeps it around so although the memory footprint is there, its swamped by GTK and there's really no cost to the dlopen as the linker reference counts for you .. Also I'll be making some fontconfig related changes fairly soon .. once I can clear my desk so to speak, so its probably not a good time to do this, even if its really going to make a difference, which I doubt. -Phil. Diego 'Flameeyes' Petten? wrote: > Forwarding to 2d-dev as asked by Oleg Sukhodolsky (originally from > awt-dev). > > Begin forwarded message: > > Date: Mon, 21 May 2007 17:45:29 +0200 > From: Diego 'Flameeyes' Petten? > To: awt-dev at openjdk.java.net > Subject: [PATCH] Allow linking in (shared) libfontconfig directy > > > As it is, OpenJDK tries to dlopen fontconfig (multiple times too), to > avoid a direct link dependency over it. This could be quite slow as the > dynamic linker has to do its job multiple times, but is understandable > for redistributable packages. > > Distributions, though, might want to just depend on fontconfig itself > and link it directly. The attached patch allows that through the > DIRECT_LINK_FONTCONFIG=true option at make. > > > > ------------------------------------------------------------------------ > > Index: openjdk/j2se/src/solaris/native/sun/awt/fontpath.c > =================================================================== > --- openjdk.orig/j2se/src/solaris/native/sun/awt/fontpath.c > +++ openjdk/j2se/src/solaris/native/sun/awt/fontpath.c > @@ -612,6 +612,9 @@ Java_sun_font_FontManager_populateFontFi > #include > #endif > > +#ifdef DIRECT_LINK_FONTCONFIG > +# include > +#else /* DIRECT_LINK_FONTCONFIG */ > #include "fontconfig.h" > > > @@ -734,21 +737,12 @@ typedef FcPattern* (*FcFontMatchFuncType > FcResult *result); > typedef FcFontSet* (*FcFontSetCreateFuncType)(); > typedef FcBool (*FcFontSetAddFuncType)(FcFontSet *s, FcPattern *font); > - > +#endif /* DIRECT_LINK_FONTCONFIG */ > > static char **getFontConfigLocations() { > > char **fontdirs; > int numdirs = 0; > - FcInitLoadConfigFuncType FcInitLoadConfig; > - FcPatternBuildFuncType FcPatternBuild; > - FcObjectSetFuncType FcObjectSetBuild; > - FcFontListFuncType FcFontList; > - FcPatternGetStringFuncType FcPatternGetString; > - FcStrDirnameFuncType FcStrDirname; > - FcPatternDestroyFuncType FcPatternDestroy; > - FcFontSetDestroyFuncType FcFontSetDestroy; > - > FcConfig *fontconfig; > FcPattern *pattern; > FcObjectSet *objset; > @@ -758,6 +752,16 @@ static char **getFontConfigLocations() { > int i, f, found, len=0; > char **fontPath; > > +#ifndef DIRECT_LINK_FONTCONFIG > + FcInitLoadConfigFuncType FcInitLoadConfig; > + FcPatternBuildFuncType FcPatternBuild; > + FcObjectSetFuncType FcObjectSetBuild; > + FcFontListFuncType FcFontList; > + FcPatternGetStringFuncType FcPatternGetString; > + FcStrDirnameFuncType FcStrDirname; > + FcPatternDestroyFuncType FcPatternDestroy; > + FcFontSetDestroyFuncType FcFontSetDestroy; > + > void* libfontconfig = openFontConfig(); > > if (libfontconfig == NULL) { > @@ -789,6 +793,7 @@ static char **getFontConfigLocations() { > closeFontConfig(libfontconfig, JNI_FALSE); > return NULL; > } > +#endif > > /* Make calls into the fontconfig library to build a search for > * outline fonts, and to get the set of full file paths from the matches. > @@ -831,7 +836,9 @@ static char **getFontConfigLocations() { > /* Free memory and close the ".so" */ > (*FcFontSetDestroy)(fontSet); > (*FcPatternDestroy)(pattern); > +#ifndef DIRECT_LINK_FONTCONFIG > closeFontConfig(libfontconfig, JNI_TRUE); > +#endif > return fontdirs; > } > > @@ -849,6 +856,7 @@ JNIEXPORT jint JNICALL > Java_sun_font_FontManager_getFontConfigAASettings > (JNIEnv *env, jclass obj, jstring localeStr, jstring fcNameStr) { > > +#ifndef DIRECT_LINK_FONTCONFIG > FcNameParseFuncType FcNameParse; > FcPatternAddStringFuncType FcPatternAddString; > FcConfigSubstituteFuncType FcConfigSubstitute; > @@ -857,6 +865,7 @@ Java_sun_font_FontManager_getFontConfigA > FcPatternGetBoolFuncType FcPatternGetBool; > FcPatternGetIntegerFuncType FcPatternGetInteger; > FcPatternDestroyFuncType FcPatternDestroy; > +#endif > > FcPattern *pattern, *matchPattern; > FcResult result; > @@ -875,6 +884,7 @@ Java_sun_font_FontManager_getFontConfigA > } > locale = (*env)->GetStringUTFChars(env, localeStr, 0); > > +#ifndef DIRECT_LINK_FONTCONFIG > if ((libfontconfig = openFontConfig()) == NULL) { > (*env)->ReleaseStringUTFChars (env, fcNameStr, (const char*)fcName); > if (locale) { > @@ -914,7 +924,7 @@ Java_sun_font_FontManager_getFontConfigA > closeFontConfig(libfontconfig, JNI_FALSE); > return -1; > } > - > +#endif > > pattern = (*FcNameParse)((FcChar8 *)fcName); > if (locale != NULL) { > @@ -938,7 +948,9 @@ Java_sun_font_FontManager_getFontConfigA > if (locale) { > (*env)->ReleaseStringUTFChars (env, localeStr, (const char*)locale); > } > +#ifndef DIRECT_LINK_FONTCONFIG > closeFontConfig(libfontconfig, JNI_TRUE); > +#endif > > if (antialias == FcFalse) { > return TEXT_AA_OFF; > @@ -960,6 +972,7 @@ JNIEXPORT void JNICALL > Java_sun_font_FontManager_getFontConfig > (JNIEnv *env, jclass obj, jstring localeStr, jobjectArray fontInfoArray) { > > +#ifndef DIRECT_LINK_FONTCONFIG > FcNameParseFuncType FcNameParse; > FcPatternAddStringFuncType FcPatternAddString; > FcConfigSubstituteFuncType FcConfigSubstitute; > @@ -967,6 +980,7 @@ Java_sun_font_FontManager_getFontConfig > FcFontMatchFuncType FcFontMatch; > FcPatternGetStringFuncType FcPatternGetString; > FcPatternDestroyFuncType FcPatternDestroy; > +#endif > > int i, arrlen; > jobject fontInfoObj; > @@ -997,6 +1011,7 @@ Java_sun_font_FontManager_getFontConfig > return; > } > > +#ifndef DIRECT_LINK_FONTCONFIG > if ((libfontconfig = openFontConfig()) == NULL) { > return; > } > @@ -1024,6 +1039,7 @@ Java_sun_font_FontManager_getFontConfig > closeFontConfig(libfontconfig, JNI_FALSE); > return; > } > +#endif > > locale = (*env)->GetStringUTFChars(env, localeStr, 0); > > @@ -1073,6 +1089,8 @@ Java_sun_font_FontManager_getFontConfig > if (locale) { > (*env)->ReleaseStringUTFChars (env, localeStr, (const char*)locale); > } > +#ifndef DIRECT_LINK_FONTCONFIG > closeFontConfig(libfontconfig, JNI_TRUE); > +#endif > } > > Index: openjdk/j2se/make/sun/awt/Makefile > =================================================================== > --- openjdk.orig/j2se/make/sun/awt/Makefile > +++ openjdk/j2se/make/sun/awt/Makefile > @@ -580,6 +580,11 @@ ifeq ($(PLATFORM), linux) > LDFLAGS += -L$(MOTIF_LIB) -L$(OPENWIN_LIB) > endif > > +ifeq ($(DIRECT_LINK_FONTCONFIG), true) > +CPPFLAGS += -DDIRECT_LINK_FONTCONFIG > +LDFLAGS += -lfontconfig > +endif > + > LDFLAGS += -L$(LIBDIR)/$(LIBARCH)/$(TSOBJDIR) \ > $(AWT_RUNPATH) > > Index: openjdk/j2se/make/sun/xawt/Makefile > =================================================================== > --- openjdk.orig/j2se/make/sun/xawt/Makefile > +++ openjdk/j2se/make/sun/xawt/Makefile > @@ -62,6 +62,11 @@ LDFLAGS += -lpthread > dummy := $(shell $(MKDIR) -p $(LIB_LOCATION)) > endif > > +ifeq ($(DIRECT_LINK_FONTCONFIG), true) > +CPPFLAGS += -DDIRECT_LINK_FONTCONFIG > +LDFLAGS += -lfontconfig > +endif > + > # Since this library will be living in a subdirectory below the other libraries > # we need to add an extra runpath so that libraries in the upper directory > # are found at runtime. From flameeyes at gmail.com Mon May 21 21:54:37 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Mon, 21 May 2007 23:54:37 +0200 Subject: [OpenJDK 2D-Dev] Fw: [PATCH] Allow linking in (shared) libfontconfig directy In-Reply-To: <4651FE87.70704@sun.com> References: <20070521221442.22b07781@enterprise.flameeyes.is-a-geek.org> <4651FE87.70704@sun.com> Message-ID: <20070521235437.5984b5c6@enterprise.flameeyes.is-a-geek.org> Hi, On Mon, 21 May 2007 13:18:15 -0700 Phil Race wrote: > Also since we dlclose, we reclaim the virtual memory, rather than > keeping it around when it will never be used again. That is there > is a very small bounded set of times when we might load this lib, > so its not something we keep coming back to. Most of the memory is freed, yes, but there are still the fontconfig files mapped anyway, as the termination function is not called. Anyway, please note that by using lazy bindings, the heaviest cost is deferred to when the functions are actually used (the binding itself); on the other hand, using direct link rather than dlopen can let libfontmanager make good use of prelinking (dlopen-ed libraries does not work with prelink out of the box, but let's not get into that right now, as it's a quite long argument of which I only know a few summaries). You should also consider that most of the modern Linux (and FreeBSD, and probably other Unix-like operating systems) desktops already have libfontconfig loaded at any time in memory, as almost every desktop environment for X11 uses it, and this makes the costs of loading libfontconfig very time almost non-existent. > Also I'll be making some fontconfig related changes > fairly soon .. once I can clear my desk so to speak, so > its probably not a good time to do this, even if its > really going to make a difference, which I doubt. Will wait then, I'm not in a hurry :) -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Phil.Race at Sun.COM Mon May 21 22:40:54 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 21 May 2007 15:40:54 -0700 Subject: [OpenJDK 2D-Dev] Fw: [PATCH] Allow linking in (shared) libfontconfig directy In-Reply-To: <20070521235437.5984b5c6@enterprise.flameeyes.is-a-geek.org> References: <20070521221442.22b07781@enterprise.flameeyes.is-a-geek.org> <4651FE87.70704@sun.com> <20070521235437.5984b5c6@enterprise.flameeyes.is-a-geek.org> Message-ID: <46521FF6.50408@sun.com> Hello, Diego 'Flameeyes' Petten? wrote: > Hi, > > On Mon, 21 May 2007 13:18:15 -0700 > Phil Race wrote: > >> Also since we dlclose, we reclaim the virtual memory, rather than >> keeping it around when it will never be used again. That is there >> is a very small bounded set of times when we might load this lib, >> so its not something we keep coming back to. > Most of the memory is freed, yes, but there are still the fontconfig > files mapped anyway, as the termination function is not called. The code is there. Its just not enabled as the function was not in the fontconfig versions on supported platforms when it was written. > > Anyway, please note that by using lazy bindings, the heaviest cost is > deferred to when the functions are actually used (the binding itself); > on the other hand, using direct link rather than dlopen can let > libfontmanager make good use of prelinking (dlopen-ed libraries does > not work with prelink out of the box, but let's not get into that right > now, as it's a quite long argument of which I only know a few > summaries). > > You should also consider that most of the modern Linux (and FreeBSD, > and probably other Unix-like operating systems) desktops already have > libfontconfig loaded at any time in memory, as almost every desktop > environment for X11 uses it, and this makes the costs of loading > libfontconfig very time almost non-existent. I could construe this either way. If its almost free it doesn't matter if you do even if you don't need it, or if you do it twice. -phil > >> Also I'll be making some fontconfig related changes >> fairly soon .. once I can clear my desk so to speak, so >> its probably not a good time to do this, even if its >> really going to make a difference, which I doubt. > Will wait then, I'm not in a hurry :) > From flameeyes at gmail.com Tue May 22 20:42:58 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Tue, 22 May 2007 22:42:58 +0200 Subject: [OpenJDK 2D-Dev] Fw: [PATCH] Allow linking in (shared) libfontconfig directy References: <20070521221442.22b07781@enterprise.flameeyes.is-a-geek.org> <4651FE87.70704@sun.com> <20070521235437.5984b5c6@enterprise.flameeyes.is-a-geek.org> <46521FF6.50408@sun.com> Message-ID: <20070522224258.616bcce7@enterprise.flameeyes.is-a-geek.org> Hi, On Mon, 21 May 2007 15:40:54 -0700 Phil Race wrote: > I could construe this either way. If its almost free it doesn't > matter if you do even if you don't need it, or if you do it twice. Right, this is why I suppose an option wouldn't be a bad idea :) Leave it up to either user or distribution to choose between the two at build time (in case of Gentoo, it would most likely become an useflag, I suppose). Oh by the way t here is one case where the direct link would be safer: if fontconfig's ABI changes, but the API doesn't, dlopen would be a problem, while direct linking would resist just fine. Of course we all hope that this will not happen (I'm scared to think about the widespread breakage due to a change in libfontconfig changing ABI). -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mr at sun.com Thu May 24 05:12:39 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 23 May 2007 22:12:39 -0700 Subject: [OpenJDK 2D-Dev] Project proposal: fbtoolkit In-Reply-To: phil.race@sun.com; Wed, 23 May 2007 21:25:52 PDT; <465513D0.3020202@sun.com> Message-ID: <20070524051239.1FF405ED5@callebaut.niobe.net> > Date: Wed, 23 May 2007 21:25:52 -0700 > From: phil.race at sun.com > Tom Marble wrote: >> Please note that following the Projects guidelines followups are >> intended to go to the discuss list [1]. > > Thats a broken process. It should go to affected groups. A Project does not necessarily need group sponsorship, which is why the interim project-proposal process doesn't define a notion of "affected groups". If the proposer of a new Project does know of one or more groups that are potential sponsors then it'd likely be more efficient to poll those groups for support before proposing the new Project, but doing so is not required. > Any assumption that every one reads or even knows about 'discuss' is > wrong and for ever will be. That's why project proposals are posted to the announce list, with follow-ups to the discuss list. Tom did in fact cc the AWT and Swing lists, though in retrospect he probably should've cc'd the 2D list as well. > So does it really make sense to propose a project you think is a cool > idea you don't understand and then disappear? > I think proposals should come only from someone who is committed to the > idea and will work on it. It would be helpful to hear answers to Phil's technical questions, either from Tom, from Steph, or from someone else who intends to work on this Project. >> Allow me to clarify, as well, that the purpose of this project >> is experimental and for prototyping. ... >> >> Can we get a Group sponsor? > > I don't think we have a clue what sponsorship means. It certainly > can't mean in this case any work from Sun engineers ( wish we had time > for such ideas ourselves), or taking it back into openjdk in any time > in the forseeable future. In the interim governance guidelines, sponsorship means only that the majority of the members of a Group think that the project is worthwhile. It does not imply any kind of commitment of effort, nor does it imply that the code will one day be integrated into any particular JDK tree. (I'll clarify this in the guidelines.) > It just seems like an interesting expt this time, with unproven > practical applications. Personally I think that the OpenJDK Community should be open to all kinds of interesting experiments. That's often, after all, the best way to learn things. - Mark From steph at tangency.co.uk Thu May 24 15:38:57 2007 From: steph at tangency.co.uk (Steph Meslin-Weber) Date: Thu, 24 May 2007 16:38:57 +0100 Subject: [OpenJDK 2D-Dev] Project proposal: fbtoolkit In-Reply-To: <4654A2A8.4020400@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> Message-ID: Hi Phil, Thanks for your comments, I wasn't certain how verbose the initial proposal was supposed to be so we left out the details from the usecases. In order to keep this thread in one list (it's starting to confuse Gmail a bit) we could continue this conversation in discuss for now. I have Bcc'd the other lists (including 2d following Mark's use) to let everyone on those lists know to check discuss for followups: Bcc: awt-dev at openjdk.java.net Bcc: 2d-dev at openjdk.java.net Bcc: swing-dev at openjdk.java.net As the discussion moves on we can move it to the one group that seems most appropriate. On 23/05/07, Phil Race wrote: > I don't follow what this has to do with Swing. 2D would be more affected .. > Swing is ignorant of whether the Motif or X toolkit is specified > and even works with the headless toolkit. Agreed, Swing shouldn't use knowledge of the underlying implementation. The reasoning behind including Swing in the discussion is the SwingAWT work by Roman Kennke. In his project, he implemented AWT peers using Swing [1]. Now, whether the Swing implementation is native is another topic of discussion :-) > Also the existing toolkits can still leverage all of the > same internal 2D native code for rendering. I don't see where > you are going to get that from unless if its going to be > a pure Java solution. I think here we tried to show that the example implementation would be written in pure Java, with extension points to break to native code as needed: "This example implementation will prefer pure-Java solutions, with public extension points available to enter native resources as necessary." Starting with pure Java means we have a baseline that is easier to understand than one that jumps back and forth to native code, this also incidentally makes it an ideal example for those wishing to write their own set of peers. It's a given that without those jumps certain optimisations aren't practical to implement, but that's why we'd like to do this in the open so those situations can be discussed and planned for. Before going on to a few usecases, I'd like to mention that I already have a fair amount of code in support of this proof of concept, including providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!) a pure Java X11 provider; there is also embryonic work on an SDL provider to ensure we cover as many platforms as possible. > > Examples of usage include: implementation debugging, device > > emulation, multiple-head clone outputs/inputs, simultaneous > > multiple-peer output, etc. Example usecases: 1) Implementation debugging is one that is fairly simple to explain, it becomes a tool for us to track down AWT/Swing issues by excluding native resources as a possible error source. (Yes it introduces another factor, but at least it's independent). This also allows for some device emulation, screen sizes, pixel encoding, etc. 2) Realtime output/input on a device (say an N800 [2]) with simultaneous output/input of the exact same screen contents on an attached PC. This is in effect multiplexing two different devices onto a single Java stack. Control of the device from the PC. Useful when your touchscreen driver isn't written yet. 3) Distributed remote software agents exposing a VNC or X11 capable UI. Easier to secure and to use than a fullblown VNC or X11 server on a dedicated host. Easier to deploy too. This is in effect a kernel+jvm+libc on any hardware. Including headless ones like a router. 4) Point of Sale, The network is the machine, etc... lightweight PXE images booting a rich Swing UI direct to their framebuffer. Small PXE image, few external dependencies. For bonus points, let the client decide which provider to load from a Jini cloud depending on need. 5) Multicast a single UI via VNC, kiosk-type advertising or interaction: one window per terminal. Please let me know if I've left a few out. Thanks, Steph [1] awtswing, http://kennke.org/~roman/swing-based-awt.png [2] N800, http://www.nseries.com/n800 [3] Maemo, http://maemo.org/ -- ================================================================ Steph Meslin-Weber, steph at tangency.co.uk ================================================================ From Jeff.Dinkins at Sun.COM Thu May 24 18:48:21 2007 From: Jeff.Dinkins at Sun.COM (Jeff Dinkins) Date: Thu, 24 May 2007 13:48:21 -0500 Subject: [OpenJDK 2D-Dev] Project proposal: fbtoolkit In-Reply-To: References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> Message-ID: Tom Marble wrote: > Can we get a Group sponsor? So a point of order: http://openjdk.java.net/projects/ "A Group makes this decision by a simple majority vote of its Members, tallied by its Moderator. If at least one Group agrees to sponsor the proposed Project within the two-week discussion period following the proposal then it will automatically be approved." 1. At some point, we'll need a call for votes from the groups involved. Can anyone make the call for vote, or does the group Moderator do it at their will, e.g. when the discussion dies down, or when 2 weeks are up? 2. Tom and Steph have asked for sponsorship from any of these groups: AWT, Swing, & 2D. Should all three take separate votes? From Jeannette.Hung at Sun.COM Fri May 25 17:35:46 2007 From: Jeannette.Hung at Sun.COM (Jeannette Hung) Date: Fri, 25 May 2007 10:35:46 -0700 Subject: [OpenJDK 2D-Dev] Project proposal: fbtoolkit In-Reply-To: <81f0d9c0705241918n4ede3f8aoc8fc7895c5f4fdaf@mail.gmail.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4655CE76.30503@sun.com> <81f0d9c0705241918n4ede3f8aoc8fc7895c5f4fdaf@mail.gmail.com> Message-ID: <46571E72.2000000@sun.com> Hey Stuart, As you probably know, we had been working feverishly to get our code in a state that we could put it out for JavaOne. The amount of software in the JDK is huge, and the amount of work that we've had to do to get it to where we currently have it has taken a lot of people and many, many hours. Because of all of that work, we haven't had much time to work out all of the rules for interim governance, and even less to communicate what's going on so some of what you are seeing is growing pains as we all build a common understanding of how this community will develop. The kinds of questions being asked by the engineers are typical ones asked internally when Sun engineers propose projects that they would like to be accepted. This is certainly necessary for us because we have to make sure that we are properly using our limited internal resources. This type of scrutiny may make less sense for projects that are staffed by non-Sun engineers. I apologize if you are feeling beleaguered -- that was not our intention. This is just the first proposal that we had seen in our groups and we hadn't heard of the notion of sponsorship before this discussion started so you caught us unawares. jeannette Stuart McCulloch wrote: > On 25/05/07, Oleg Sukhodolsky wrote: >> imho all functionality suggested could be achieved by fb-based XServer, >> why do you need to reinvent the wheel and develop a toolkit which will >> implement some functionality of XServer, some functionality of Window >> Manager, and AWT toolkit. >> >> What is the advantage of the approach you suggest? > > perhaps better use of memory/resources? > > sometimes a bit of (re)invention can uncover new and interesting paths... > > On 24/05/07, Phil Race wrote: >> I don't think we have a clue what sponsorship means. It certainly can't >> mean in this case any work from Sun engineers ( wish we had time for >> such ideas ourselves), or taking it back into openjdk in any time in the >> forseeable future. > > I guess the question I have about this discussion is whether openjdk > is just a place to grab the JDK source, or whether it's a place where > people can really take part, innovate and contribute back? > >> >> Thanks, Oleg. >> >> Steph Meslin-Weber wrote: >> > Hi Phil, >> > >> > Thanks for your comments, I wasn't certain how verbose the initial >> > proposal was supposed to be so we left out the details from the >> > usecases. >> > >> > In order to keep this thread in one list (it's starting to confuse >> > Gmail a bit) we could continue this conversation in discuss for now. >> > I have Bcc'd the other lists (including 2d following Mark's use) to >> > let everyone on those lists know to check discuss for followups: >> > Bcc: awt-dev at openjdk.java.net >> > Bcc: 2d-dev at openjdk.java.net >> > Bcc: swing-dev at openjdk.java.net >> > As the discussion moves on we can move it to the one group that seems >> > most appropriate. >> > >> > On 23/05/07, Phil Race wrote: >> >> I don't follow what this has to do with Swing. 2D would be more >> >> affected .. >> >> Swing is ignorant of whether the Motif or X toolkit is specified >> >> and even works with the headless toolkit. >> > >> > Agreed, Swing shouldn't use knowledge of the underlying >> > implementation. The reasoning behind including Swing in the discussion >> > is the SwingAWT work by Roman Kennke. In his project, he implemented >> > AWT peers using Swing [1]. Now, whether the Swing implementation is >> > native is another topic of discussion :-) >> > >> >> Also the existing toolkits can still leverage all of the >> >> same internal 2D native code for rendering. I don't see where >> >> you are going to get that from unless if its going to be >> >> a pure Java solution. >> > >> > I think here we tried to show that the example implementation would be >> > written in pure Java, with extension points to break to native code as >> > needed: >> > >> > "This example implementation will prefer pure-Java solutions, with >> > public extension points available to enter native resources as >> > necessary." >> > >> > Starting with pure Java means we have a baseline that is easier to >> > understand than one that jumps back and forth to native code, this >> > also incidentally makes it an ideal example for those wishing to write >> > their own set of peers. It's a given that without those jumps certain >> > optimisations aren't practical to implement, but that's why we'd like >> > to do this in the open so those situations can be discussed and >> > planned for. >> > >> > >> > Before going on to a few usecases, I'd like to mention that I already >> > have a fair amount of code in support of this proof of concept, >> including >> > providers for raw linux fb, VNC and (as of 2 hours ago, thanks >> Guillaume!) >> > a pure Java X11 provider; there is also embryonic work on an SDL >> provider >> > to ensure we cover as many platforms as possible. >> > >> >> > Examples of usage include: implementation debugging, device >> >> > emulation, multiple-head clone outputs/inputs, simultaneous >> >> > multiple-peer output, etc. >> > >> > Example usecases: >> > >> > 1) Implementation debugging is one that is fairly simple to explain, >> > it becomes a tool for us to track down AWT/Swing issues by excluding >> > native resources as a possible error source. (Yes it introduces >> > another factor, but at least it's independent). This also allows for >> > some device emulation, screen sizes, pixel encoding, etc. >> > >> > 2) Realtime output/input on a device (say an N800 [2]) with >> > simultaneous output/input of the exact same screen contents on an >> > attached PC. This is in effect multiplexing two different devices >> onto >> > a single Java stack. Control of the device from the PC. Useful when >> > your touchscreen driver isn't written yet. >> > >> > 3) Distributed remote software agents exposing a VNC or X11 capable >> > UI. Easier to secure and to use than a fullblown VNC or X11 server on >> > a dedicated host. Easier to deploy too. This is in effect a >> > kernel+jvm+libc on any hardware. Including headless ones like a >> > router. >> > >> > 4) Point of Sale, The network is the machine, etc... lightweight PXE >> > images booting a rich Swing UI direct to their framebuffer. Small PXE >> > image, few external dependencies. For bonus points, let the client >> > decide which provider to load from a Jini cloud depending on need. >> > >> > 5) Multicast a single UI via VNC, kiosk-type advertising or >> > interaction: one window per terminal. >> > >> > Please let me know if I've left a few out. >> > >> > Thanks, >> > Steph >> > >> > [1] awtswing, http://kennke.org/~roman/swing-based-awt.png >> > [2] N800, http://www.nseries.com/n800 >> > [3] Maemo, http://maemo.org/ >> > >> >