From flameeyes at gmail.com Fri May 11 13:04:10 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 11 May 2007 22:04:10 +0200 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen Message-ID: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> Trying to make OpenJDK more friendly for those distributions (like Gentoo and Debian iirc) having in their policy the use, whenever possible, of the system's libraries rather than internal copies of them, I've prepared three patches to AWT's libsplashscreen that allows to use the external/system copy of the three libraries in the subject. The default behaviour is unchanged, you need to pass EXTERNAL_JPEG EXTERNAL_LIBPNG and EXTERNAL_GIFLIB with the value "true" to get them used. Hope this helps, -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-external-giflib.patch Type: text/x-patch Size: 1045 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070511/cd477b89/openjdk-external-giflib.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-external-jpeg-splash.patch Type: text/x-patch Size: 2637 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070511/cd477b89/openjdk-external-jpeg-splash.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-external-libpng.patch Type: text/x-patch Size: 1215 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070511/cd477b89/openjdk-external-libpng.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070511/cd477b89/signature.asc From Anthony.Petrov at Sun.COM Mon May 14 06:03:41 2007 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Mon, 14 May 2007 17:03:41 +0400 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen In-Reply-To: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> References: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> Message-ID: <46485E2D.9040008@sun.com> Hello Diego, Thanks for the patches. Though, we've got a number of reasons not to apply them currently: 1. Not every *NIX desktop has these libraries installed. Throwing them out means adding more external dependencies that are not regularly required now. 2. Some libraries bundled with the JDK (like the libjpeg) are heavily customized by Sun. Using system copy of such library might cause unexpected behavior of JDK. 3. Also using system copies of libraries might be unreliable, and thus some bugs could arise that we do not expect. This situation would be difficult as it would not be clear whether it's an OpenJDK fault, or the library fault. At least until we've got an ability to retrieve some specific options (like EXTERNAL_LIBPNG) that were used while building OpenJDK from the run-time version (i.e. something like a switch 'java -Xprintconfigoptions'). So, even taking into account that the patch does not change the default behavior, we think that the number of problems it could bring is to big. What do you think about these reasons? And, what's more important, what, in your opinion, is the main reason for such an addition to OpenJDK? -- best regards, Anthony On 05/12/2007 12:04 AM Diego 'Flameeyes' Petten? wrote: > Trying to make OpenJDK more friendly for those distributions (like > Gentoo and Debian iirc) having in their policy the use, whenever > possible, of the system's libraries rather than internal copies of > them, I've prepared three patches to AWT's libsplashscreen that allows > to use the external/system copy of the three libraries in the subject. > > The default behaviour is unchanged, you need to pass EXTERNAL_JPEG > EXTERNAL_LIBPNG and EXTERNAL_GIFLIB with the value "true" to get them > used. > > Hope this helps, > From flameeyes at gmail.com Mon May 14 09:34:01 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Mon, 14 May 2007 18:34:01 +0200 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen In-Reply-To: <46485E2D.9040008@sun.com> References: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> <46485E2D.9040008@sun.com> Message-ID: <20070514183401.6e8d1567@enterprise.flameeyes.is-a-geek.org> Hi, On Mon, 14 May 2007 17:03:41 +0400 Anthony Petrov wrote: > 1. Not every *NIX desktop has these libraries installed. Throwing > them out means adding more external dependencies that are not > regularly required now. Okay, I suppose I can agree on it for giflib that isn't really a common library, but I'd be very surprised for a Solaris, Linux, or even FreeBSD and NetBSD *desktop* not to have libpng, or libjpeg. Of course the keyword here is desktop, as probably OpenJDK is going to be used not only on desktop systems where the libraries are likely not to be present (they are not present on my server either, and there I'd like to run Tomcat sooner or later - that is when I can get OpenJDK to build on FreeBSD). But, these patches are thought to be there for distributions building their own package of OpenJDK, and distributions can put their own dependencies over and live peacefully. On the other hand, OpenJDK already uses alsa-lib externally, and so is going to do for FreeType, standing from what I read from Phil Race on build-dev. > 2. Some libraries bundled with the JDK (like the libjpeg) are heavily > customized by Sun. Using system copy of such library might cause > unexpected behavior of JDK. This has been and is being discussed on build-dev too; Phil also said that as far as he knows giflib and libpng are not modified except for removing extra stuff, which is understandable. The changes in libjpeg does not seem to be important for the splashscreen support either, and for those there's still the discussion going; many distributions will more likely merge the changes in their own libjpeg packages and use those rather than having an extra internal copy. > 3. Also using system copies of libraries might be unreliable, and > thus some bugs could arise that we do not expect. This situation > would be difficult as it would not be clear whether it's an OpenJDK > fault, or the library fault. At least until we've got an ability to > retrieve some specific options (like EXTERNAL_LIBPNG) that were used > while building OpenJDK from the run-time version (i.e. something like > a switch 'java -Xprintconfigoptions'). Okay, that is a good point, having a way to tell how something has been built is certainly helpful; too bad I have no idea how to implement it myself or I'd do, but I'll see if I can get to look at it. > And, what's more > important, what, in your opinion, is the main reason for such an > addition to OpenJDK? As I said, Gentoo, Debian, most likely RedHat, as far as I know also FreeBSD, and probably many other distributions too have a policy to avoid using internal copies of libraries whenever humanly feasible. This is due not only for a performance/space reason (a libpng shared across 20 processes in a KDE desktop has a risible memory cost in term of shared pages; a copy of it in other ten process having a local copy each instead is a waste of memory and address space too), but also because if a bugfix (especially a security one) has to be applied to a library, using shared libraries you just have to apply it once, and ship out the new package for the library, rather than having to apply it on and ship ten or more packages. Gary Benson from RedHat already shown the case for zlib[1]; I can provide my experience with the upgrade of FreeType, when they dropped the internal API: at least three packages had to be updated because they inlined a copy of SDL_ttf, an old version that was still using the old API, while SDL_ttf itself was already fixed to use the new one, and didn't change API by itself; having a way to use the external copy would have saved a lot of time to both us distributors and to users who had to recompile them. Although I suppose that changes in API for libpng/giflib/libjpeg are unlikely, or would be anyway enough of an hassle to make them unfeasible on the short term, considering their widespread use, security concerns aren't really non-existent. E.g. libpng had a vulnerability discovered last november[2], jpeg last june[3], while giflib had two in september[4] and october[5] 2005. [1] http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5793 [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3005 [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3350 [5] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2974 -- 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 : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070514/d507e985/signature.asc From Phil.Race at Sun.COM Mon May 14 12:32:20 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 14 May 2007 12:32:20 -0700 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen In-Reply-To: <20070514183401.6e8d1567@enterprise.flameeyes.is-a-geek.org> References: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> <46485E2D.9040008@sun.com> <20070514183401.6e8d1567@enterprise.flameeyes.is-a-geek.org> Message-ID: <4648B944.2010309@sun.com> So long as the changes don't break/affect our internal build and can be constrained to non-default build options, not code changes, they are probably OK. The security issues are something we should think about. Certainly we should keep up to date on patches. libgif and libpng are only in JDK since 1.6, and the same is true for splashscreen's use of openjdk so there's not too much history there to worry about yet. >> a switch 'java -Xprintconfigoptions'). .. > having a way to tell how something has been > built is certainly helpful; Maybe we need an RFE on this, although libs in use should show up in a hotspot log or core. In the short term, if Gentoo is building for Gentoo, then putting something in the "build" portion of the string emitted by -version may be a quick way to tell its a Gentoo-specific build. BTW, Did you send in your SCA yet? -phil. Diego 'Flameeyes' Petten? wrote: > Hi, > > On Mon, 14 May 2007 17:03:41 +0400 > Anthony Petrov wrote: >> 1. Not every *NIX desktop has these libraries installed. Throwing >> them out means adding more external dependencies that are not >> regularly required now. > Okay, I suppose I can agree on it for giflib that isn't really a common > library, but I'd be very surprised for a Solaris, Linux, or even > FreeBSD and NetBSD *desktop* not to have libpng, or libjpeg. > Of course the keyword here is desktop, as probably OpenJDK is going to > be used not only on desktop systems where the libraries are likely not > to be present (they are not present on my server either, and there I'd > like to run Tomcat sooner or later - that is when I can get OpenJDK to > build on FreeBSD). > > But, these patches are thought to be there for distributions building > their own package of OpenJDK, and distributions can put their own > dependencies over and live peacefully. > On the other hand, OpenJDK already uses alsa-lib externally, and so is > going to do for FreeType, standing from what I read from Phil Race on > build-dev. > >> 2. Some libraries bundled with the JDK (like the libjpeg) are heavily >> customized by Sun. Using system copy of such library might cause >> unexpected behavior of JDK. > This has been and is being discussed on build-dev too; Phil also said > that as far as he knows giflib and libpng are not modified except for > removing extra stuff, which is understandable. The changes in libjpeg > does not seem to be important for the splashscreen support either, and > for those there's still the discussion going; many distributions will > more likely merge the changes in their own libjpeg packages and use > those rather than having an extra internal copy. > >> 3. Also using system copies of libraries might be unreliable, and >> thus some bugs could arise that we do not expect. This situation >> would be difficult as it would not be clear whether it's an OpenJDK >> fault, or the library fault. At least until we've got an ability to >> retrieve some specific options (like EXTERNAL_LIBPNG) that were used >> while building OpenJDK from the run-time version (i.e. something like >> a switch 'java -Xprintconfigoptions'). > Okay, that is a good point, having a way to tell how something has been > built is certainly helpful; too bad I have no idea how to implement it > myself or I'd do, but I'll see if I can get to look at it. > >> And, what's more >> important, what, in your opinion, is the main reason for such an >> addition to OpenJDK? > > As I said, Gentoo, Debian, most likely RedHat, as far as I know > also FreeBSD, and probably many other distributions too have a policy > to avoid using internal copies of libraries whenever humanly feasible. > This is due not only for a performance/space reason (a libpng shared > across 20 processes in a KDE desktop has a risible memory cost in term > of shared pages; a copy of it in other ten process having a local copy > each instead is a waste of memory and address space too), but also > because if a bugfix (especially a security one) has to be applied to a > library, using shared libraries you just have to apply it once, and > ship out the new package for the library, rather than having to apply > it on and ship ten or more packages. > Gary Benson from RedHat already shown the case for zlib[1]; I can > provide my experience with the upgrade of FreeType, when they dropped > the internal API: at least three packages had to be updated because > they inlined a copy of SDL_ttf, an old version that was still using the > old API, while SDL_ttf itself was already fixed to use the new one, and > didn't change API by itself; having a way to use the external copy > would have saved a lot of time to both us distributors and to users who > had to recompile them. > > Although I suppose that changes in API for libpng/giflib/libjpeg are > unlikely, or would be anyway enough of an hassle to make them > unfeasible on the short term, considering their widespread use, > security concerns aren't really non-existent. > E.g. libpng had a vulnerability discovered last > november[2], jpeg last june[3], while giflib had two in september[4] and > october[5] 2005. > > [1] > http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html > [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5793 > [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3005 > [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3350 > [5] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2974 From flameeyes at gmail.com Mon May 14 13:34:56 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Mon, 14 May 2007 22:34:56 +0200 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen In-Reply-To: <4648B944.2010309@sun.com> References: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> <46485E2D.9040008@sun.com> <20070514183401.6e8d1567@enterprise.flameeyes.is-a-geek.org> <4648B944.2010309@sun.com> Message-ID: <20070514223456.6bcf6ef4@enterprise.flameeyes.is-a-geek.org> On Mon, 14 May 2007 12:32:20 -0700 Phil Race wrote: > The security issues are something we should think about. > Certainly we should keep up to date on patches. That is probably a wise decision, whatever the outcome of the usage of external libraries is :) For what it's worth, I can give a couple of suggestion about it through my experience with xine: move all the contributed code in a different directory, don't put the sources for your own code in that tree, and always keep an updated diff between the original code and your imported code in there, so that if you need to upgrade you can just apply the diff over it. Of course it would also help to send the changes to the original projects so that they can include them as soon as possible, skipping over the need to fix the patches if a new version changes the source code a bit in organisation. > libgif and libpng are only in JDK since 1.6, and the same is > true for splashscreen's use of openjdk so there's not too > much history there to worry about yet. Well, at least the code of libpng is in the b12 package of OpenJDK *is* vulnerable to CVE-2006-5793. Unfortunately I wasn't able to find a proof of concept of it to actually check if the release 1.6 had that problem, but the codepath is unchanged, the libpng version is older than the current release, quite older. I suppose you can probably either import a new version of libpng or apply the simple patch to fix the issue. > In the short term, if Gentoo is building for Gentoo, then > putting something in the "build" portion of the string emitted > by -version may be a quick way to tell its a Gentoo-specific build. Well, unless the user is playing with options (which would make it difficult anyway to find out what the user is doing), it's already possible to identify a build out of Gentoo's ebuild: openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-portage_14_may_2007_15_18-b00) OpenJDK 64-Bit Server VM (build 1.7.0-internal-portage_14_may_2007_15_18-b00, mixed mode) you embed already the user under which OpenJDK is built; for Gentoo, that user will usually be 'portage'. > BTW, Did you send in your SCA yet? I didn't before, but I just sent it in a few minutes ago. Regards, -- 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 : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070514/c81bb457/signature.asc From Anthony.Petrov at Sun.COM Wed May 16 05:42:51 2007 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 16 May 2007 16:42:51 +0400 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen In-Reply-To: <20070514223456.6bcf6ef4@enterprise.flameeyes.is-a-geek.org> References: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> <46485E2D.9040008@sun.com> <20070514183401.6e8d1567@enterprise.flameeyes.is-a-geek.org> <4648B944.2010309@sun.com> <20070514223456.6bcf6ef4@enterprise.flameeyes.is-a-geek.org> Message-ID: <464AFC4B.9070407@sun.com> Hello Diego, The reasons are quite reasonable. We think we can apply the patch. However, we should wait a bit until some bureaucracy is done to make sure your signed SCA has been properly enlisted. Thank you! -- best regards, Anthony On 05/15/2007 12:34 AM Diego 'Flameeyes' Petten? wrote: > On Mon, 14 May 2007 12:32:20 -0700 > Phil Race wrote: > >> The security issues are something we should think about. >> Certainly we should keep up to date on patches. > That is probably a wise decision, whatever the outcome of the usage of > external libraries is :) > For what it's worth, I can give a couple of suggestion about it through > my experience with xine: move all the contributed code in a different > directory, don't put the sources for your own code in that tree, and > always keep an updated diff between the original code and your imported > code in there, so that if you need to upgrade you can just apply the > diff over it. > > Of course it would also help to send the changes to the original > projects so that they can include them as soon as possible, skipping > over the need to fix the patches if a new version changes the source > code a bit in organisation. > >> libgif and libpng are only in JDK since 1.6, and the same is >> true for splashscreen's use of openjdk so there's not too >> much history there to worry about yet. > Well, at least the code of libpng is in the b12 package of OpenJDK *is* > vulnerable to CVE-2006-5793. Unfortunately I wasn't able to find a > proof of concept of it to actually check if the release 1.6 had that > problem, but the codepath is unchanged, the libpng version is older > than the current release, quite older. I suppose you can probably > either import a new version of libpng or apply the simple patch to fix > the issue. > >> In the short term, if Gentoo is building for Gentoo, then >> putting something in the "build" portion of the string emitted >> by -version may be a quick way to tell its a Gentoo-specific build. > Well, unless the user is playing with options (which would make it > difficult anyway to find out what the user is doing), it's already > possible to identify a build out of Gentoo's ebuild: > > openjdk version "1.7.0-internal" > OpenJDK Runtime Environment (build > 1.7.0-internal-portage_14_may_2007_15_18-b00) OpenJDK 64-Bit Server VM > (build 1.7.0-internal-portage_14_may_2007_15_18-b00, mixed mode) > > you embed already the user under which OpenJDK is built; for Gentoo, > that user will usually be 'portage'. > >> BTW, Did you send in your SCA yet? > I didn't before, but I just sent it in a few minutes ago. > > Regards, From flameeyes at gmail.com Fri May 18 07:12:09 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Fri, 18 May 2007 16:12:09 +0200 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen In-Reply-To: <464AFC4B.9070407@sun.com> References: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> <46485E2D.9040008@sun.com> <20070514183401.6e8d1567@enterprise.flameeyes.is-a-geek.org> <4648B944.2010309@sun.com> <20070514223456.6bcf6ef4@enterprise.flameeyes.is-a-geek.org> <464AFC4B.9070407@sun.com> Message-ID: <20070518161209.300530ec@enterprise.flameeyes.is-a-geek.org> On Wed, 16 May 2007 16:42:51 +0400 Anthony Petrov wrote: > The reasons are quite reasonable. We think we can apply the patch. > However, we should wait a bit until some bureaucracy is done to make > sure your signed SCA has been properly enlisted. Thank you! Having to wait proved lucky enough: the internal headers for png.h and gif_lib.h were being used with my previous patches, the attached ones fixes the issue. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-external-giflib.patch Type: text/x-patch Size: 1608 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070518/e37542de/openjdk-external-giflib.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-external-libpng.patch Type: text/x-patch Size: 1696 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070518/e37542de/openjdk-external-libpng.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070518/e37542de/signature.asc From Tom.Marble at Sun.COM Sat May 19 14:02:34 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Sat, 19 May 2007 16:02:34 -0500 Subject: test message Message-ID: <464F65EA.6080506@sun.com> All: Please ignore this test message. --Tom From flameeyes at gmail.com Sun May 20 11:16:11 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Sun, 20 May 2007 20:16:11 +0200 Subject: [PATCH] Add option to use external libXinerama Message-ID: <20070520201611.5ed72228@enterprise.flameeyes.is-a-geek.org> Yet another external patch, the attached one adds an EXTERNAL_XINERAMA option that allows to link to the system's libXinerama library rather than using the internal copy of it. I hoped that doing so would have fixed jconsole appearing between the two screens, but it didn't do so (gonna debug it soon); in the mean time it's still a nice thing to use it shared, as for those who actually use Xinerama, the library is for sure already loaded at any given time. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-external-libXinerama.patch Type: text/x-patch Size: 1353 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070520/1be0ea36/openjdk-external-libXinerama.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070520/1be0ea36/signature.asc From flameeyes at gmail.com Mon May 21 08:45:29 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Mon, 21 May 2007 17:45:29 +0200 Subject: [PATCH] Allow linking in (shared) libfontconfig directy Message-ID: <20070521174529.15c50fdc@enterprise.flameeyes.is-a-geek.org> 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/ -------------- 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 : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070521/052245c4/openjdk-fontconfig-directlink.patch.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070521/052245c4/signature.asc From Oleg.Sukhodolsky at Sun.COM Mon May 21 09:14:14 2007 From: Oleg.Sukhodolsky at Sun.COM (Oleg Sukhodolsky) Date: Mon, 21 May 2007 20:14:14 +0400 Subject: [PATCH] Allow linking in (shared) libfontconfig directy In-Reply-To: <20070521174529.15c50fdc@enterprise.flameeyes.is-a-geek.org> References: <20070521174529.15c50fdc@enterprise.flameeyes.is-a-geek.org> Message-ID: <4651C556.5070606@sun.com> Hi Diego, font manager is owned by 2D team, could you, please, resubmit your path to 2d-dev at openjdk.java.net alias. Thanks, Oleg. Diego 'Flameeyes' Petten? wrote: > 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 Tom.Marble at Sun.COM Wed May 23 13:01:48 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 23 May 2007 15:01:48 -0500 Subject: Project proposal: fbtoolkit Message-ID: <46549DAC.30501@sun.com> All: In conjunction with Steph Meslin-Weber [1] I would like to propose a new OpenJDK project: fbtoolkit The objective of this project is to produce a body of code which is a lightweight framebuffer-based peer implementation for AWT and Swing. The goal of this code is to remove the dependency on X or other graphics layers such that graphics can be redirected to a framebuffer (e.g. a raw buffer, VNC, etc.). This example implementation will prefer pure-Java solutions, with public extension points available to enter native resources as necessary. In prototyping this functionality with OpenJDK it should be possible demonstrate this graphics redirection via a command line such as: % java -Dawt.toolkit=net.java.openjdk.fbtoolkit.Toolkit -jar myApp.jar NOTE: there are many other options which one would want to specify (e.g. bit depth, encoding, geometry, port number, etc.) and these can all be collected into a properties file which is implicitly named (based upon the provider) or overridden on the command line. Examples of usage include: implementation debugging, device emulation, multiple-head clone outputs/inputs, simultaneous multiple-peer output, etc. As this proposal is most closely related to the AWT [2] and Swing [3] groups they have been added on CC: and as such we would like to request sponsorship from these groups. Please note that per the interim OpenJDK guidelines for Projects [4] that followups should go the discuss list [5]. Thank you for your consideration, --Tom & Steph [1] Steph is a Participant Steph's blog: http://blog.tangency.co.uk/ java.net ident: twiun [2] the AWT Group: http://openjdk.java.net/groups/awt/ [3] the Swing Group: http://openjdk.java.net/groups/swing/ [4] Proposing Projects: http://openjdk.java.net/projects/ [5] discuss: http://mail.openjdk.java.net/mailman/listinfo/discuss From Phil.Race at Sun.COM Wed May 23 13:23:04 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 23 May 2007 13:23:04 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: <46549DAC.30501@sun.com> References: <46549DAC.30501@sun.com> Message-ID: <4654A2A8.4020400@sun.com> 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. 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. -phil. Tom Marble wrote: > All: > > In conjunction with Steph Meslin-Weber [1] I would like to propose > a new OpenJDK project: fbtoolkit > > The objective of this project is to produce a body of code which is > a lightweight framebuffer-based peer implementation for AWT and Swing. > The goal of this code is to remove the dependency on X or > other graphics layers such that graphics can be redirected to > a framebuffer (e.g. a raw buffer, VNC, etc.). This example > implementation will prefer pure-Java solutions, with public > extension points available to enter native resources as necessary. > > In prototyping this functionality with OpenJDK it > should be possible demonstrate this graphics redirection > via a command line such as: > % java -Dawt.toolkit=net.java.openjdk.fbtoolkit.Toolkit -jar myApp.jar > > NOTE: there are many other options which one would want > to specify (e.g. bit depth, encoding, geometry, port number, etc.) and > these can all be collected into a properties file which is > implicitly named (based upon the provider) or overridden on > the command line. > > Examples of usage include: implementation debugging, device > emulation, multiple-head clone outputs/inputs, simultaneous > multiple-peer output, etc. > > As this proposal is most closely related to the AWT [2] and Swing [3] > groups they have been added on CC: and as such we would like to > request sponsorship from these groups. > > Please note that per the interim OpenJDK guidelines for Projects [4] > that followups should go the discuss list [5]. > > Thank you for your consideration, > > --Tom & Steph > > [1] Steph is a Participant > Steph's blog: http://blog.tangency.co.uk/ > java.net ident: twiun > [2] the AWT Group: http://openjdk.java.net/groups/awt/ > [3] the Swing Group: http://openjdk.java.net/groups/swing/ > [4] Proposing Projects: http://openjdk.java.net/projects/ > [5] discuss: http://mail.openjdk.java.net/mailman/listinfo/discuss > > From Phil.Race at Sun.COM Wed May 23 21:25:52 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 23 May 2007 21:25:52 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: <4654EE52.6010605@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4654EE52.6010605@sun.com> Message-ID: <465513D0.3020202@sun.com> Tom Marble wrote: > 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. >> >> 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. >> > > 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. Any assumption that every one reads or even knows about 'discuss' is wrong and for ever will be. > I confess I am not a client or graphics expert. I can appreciate > the advantages, however, of device emulation and multiple-head > clone outputs/inputs, etc. If Swing is less appropriate than 2D > then perhaps 2D would be a more appropriate Group to sponsor this > Project? > 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. > Allow me to clarify, as well, that the purpose of this project > is experimental and for prototyping. Think of this as a KSL [2] > style Project that should be associated with the appropriate > Group (i.e. 2D or AWT). Obviously such a Project, if approved, would > need a VCS "sandbox" as described in [1]: "Projects that are not > tightly related to the development of JDK 7 will, for now, also be > given a regular java.net project within the java.net OpenJDK Community." > > 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. It just seems like an interesting expt this time, with unproven practical applications. -Phil > --Tom > > [1] http://openjdk.java.net/projects/ > [2] http://blogs.sun.com/ahe/entry/ksl_open > From mr at sun.com Wed May 23 22:12:39 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 23 May 2007 22:12:39 -0700 Subject: 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 Joshua.Marinacci at Sun.COM Thu May 24 08:34:25 2007 From: Joshua.Marinacci at Sun.COM (Joshua Marinacci) Date: Thu, 24 May 2007 08:34:25 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: <465513D0.3020202@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4654EE52.6010605@sun.com> <465513D0.3020202@sun.com> Message-ID: I'm not sure who exactly would want to sponsor this project and which teams would be involved. Since AWT, 2D, and Swing are so closely related they would likely all be involved. I can speak, however, to the practical need for this project. There are many use cases for a completely virtualized toolkit. * www.glossitope.org This is a project I started which lets you write widgets that run on your desktop in Java. The version I prepared for JavaOne has lots of cool effects that involve scaling, shearing, and otherwise animating the widgets in weird ways. Since the widgets are just Swing panels I draw them into buffered images and then blit those to the screen. This has lots of odd problems that are hard to fix properly, such as dealing with focus, handling combobox popups, and keyboard events. These problems are difficult (if not impossible) to solve outside of core. * Project Looking Glass Paul Byrne and I have discussed this extensively and he even had another researcher start building a headless AWT that could be projected into the Java3D scene graph. They got pretty far but ran into a few places where AWT assumes it has a real windowing system with access to X11 window handles. These are also impossible to fix without changes to core. Solveing this would let them put Swing applications directly into the 3d environment * JOGL Minimal Scene Graph Ken Russell and others would like to project Swing components directly into the JOGL scene graph that they are building. This would let you have a Swing panel that appears normal but can then slide into the background to be replaced by other panel. * full screen video games We would like to let people use Swing components as the heads up display in full screen video games. This means running in an environment where there is no windowing system at all. This would also be useful for kiosks and other semi-embedded environments. So you can see, there is a great need for a virtualized Toolkit. I think that most of the work could be done at the AWT level (and hopefully let me scrap most of my Swing level hacks) but undoubtedly it will affect many areas in core. This is something that is vitally needed to let us take Java SE into new environments. thx, Josh >> Allow me to clarify, as well, that the purpose of this project >> is experimental and for prototyping. Think of this as a KSL [2] >> style Project that should be associated with the appropriate >> Group (i.e. 2D or AWT). Obviously such a Project, if approved, would >> need a VCS "sandbox" as described in [1]: "Projects that are not >> tightly related to the development of JDK 7 will, for now, also be >> given a regular java.net project within the java.net OpenJDK >> Community." >> >> 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. > > It just seems like an interesting expt this time, with unproven > practical applications. - Blasting forth in three part harmony! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070524/8160f0a3/attachment.html From steph at tangency.co.uk Thu May 24 08:38:57 2007 From: steph at tangency.co.uk (Steph Meslin-Weber) Date: Thu, 24 May 2007 16:38:57 +0100 Subject: 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 Dmitri.Trembovetski at Sun.COM Thu May 24 09:46:56 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 24 May 2007 09:46:56 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4654EE52.6010605@sun.com> <465513D0.3020202@sun.com> Message-ID: <4655C180.1050100@Sun.COM> > * full screen video games > We would like to let people use Swing components as the heads up > display in full screen video games. This means running in an environment > where there is no windowing system at all. This would also be useful > for kiosks and other semi-embedded environments. You can do that right now, Swing works (mostly) fine in fullscreen mode. Thanks, Dmitri Joshua Marinacci wrote: > I'm not sure who exactly would want to sponsor this project and which > teams would be involved. Since AWT, 2D, and Swing are so closely related > they would likely all be involved. I can speak, however, to the > practical need for this project. There are many use cases for a > completely virtualized toolkit. > > * www.glossitope.org > This is a project I started which lets you write widgets that run on > your desktop in Java. The version I prepared for JavaOne has lots of > cool effects that involve scaling, shearing, and otherwise animating the > widgets in weird ways. Since the widgets are just Swing panels I draw > them into buffered images and then blit those to the screen. This has > lots of odd problems that are hard to fix properly, such as dealing with > focus, handling combobox popups, and keyboard events. These problems > are difficult (if not impossible) to solve outside of core. > > * Project Looking Glass > Paul Byrne and I have discussed this extensively and he even had > another researcher start building a headless AWT that could be projected > into the Java3D scene graph. They got pretty far but ran into a few > places where AWT assumes it has a real windowing system with access to > X11 window handles. These are also impossible to fix without changes to > core. Solveing this would let them put Swing applications directly into > the 3d environment > > * JOGL Minimal Scene Graph > Ken Russell and others would like to project Swing components directly > into the JOGL scene graph that they are building. This would let you > have a Swing panel that appears normal but can then slide into the > background to be replaced by other panel. > > * full screen video games > We would like to let people use Swing components as the heads up > display in full screen video games. This means running in an environment > where there is no windowing system at all. This would also be useful > for kiosks and other semi-embedded environments. > > > So you can see, there is a great need for a virtualized Toolkit. I think > that most of the work could be done at the AWT level (and hopefully let > me scrap most of my Swing level hacks) but undoubtedly it will affect > many areas in core. This is something that is vitally needed to let us > take Java SE into new environments. > > thx, > Josh > >>> Allow me to clarify, as well, that the purpose of this project >>> is experimental and for prototyping. Think of this as a KSL [2] >>> style Project that should be associated with the appropriate >>> Group (i.e. 2D or AWT). Obviously such a Project, if approved, would >>> need a VCS "sandbox" as described in [1]: "Projects that are not >>> tightly related to the development of JDK 7 will, for now, also be >>> given a regular java.net project within the java.net OpenJDK Community." >>> >>> 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. >> >> It just seems like an interesting expt this time, with unproven >> practical applications. > > > > - Blasting forth in three part harmony! > > From Jeff.Dinkins at Sun.COM Thu May 24 11:48:21 2007 From: Jeff.Dinkins at Sun.COM (Jeff Dinkins) Date: Thu, 24 May 2007 13:48:21 -0500 Subject: 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 10:35:46 2007 From: Jeannette.Hung at Sun.COM (Jeannette Hung) Date: Fri, 25 May 2007 10:35:46 -0700 Subject: 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/ >> > >> > From flameeyes at gmail.com Thu May 31 05:17:32 2007 From: flameeyes at gmail.com (Diego 'Flameeyes' =?UTF-8?B?UGV0dGVuw7I=?=) Date: Thu, 31 May 2007 14:17:32 +0200 Subject: [PATCHes] Allow using system's copies of libjpeg, libpng and giflib for splashscreen In-Reply-To: <464AFC4B.9070407@sun.com> References: <20070511220410.6b305770@enterprise.flameeyes.is-a-geek.org> <46485E2D.9040008@sun.com> <20070514183401.6e8d1567@enterprise.flameeyes.is-a-geek.org> <4648B944.2010309@sun.com> <20070514223456.6bcf6ef4@enterprise.flameeyes.is-a-geek.org> <464AFC4B.9070407@sun.com> Message-ID: <20070531141732.312f840d@enterprise.flameeyes.is-a-geek.org> Hi, On Wed, 16 May 2007 16:42:51 +0400 Anthony Petrov wrote: > However, we should wait a bit until some bureaucracy is done to make > sure your signed SCA has been properly enlisted. Thank you! My SCA was accepted last night (in my timezone at least), so I suppose it's good to go now. I'm attaching the last revisions of the patches for completeness; the jpeg version only allows external linking of splashscreen and doesn't touch the jni stuff that requires the modified version. -- Diego "Flameeyes" Petten? http://farragut.flameeyes.is-a-geek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: external-giflib.patch Type: text/x-patch Size: 1608 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070531/5b333d88/external-giflib.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: external-jpeg-splash.patch Type: text/x-patch Size: 2673 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070531/5b333d88/external-jpeg-splash.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: external-libpng.patch Type: text/x-patch Size: 1696 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070531/5b333d88/external-libpng.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20070531/5b333d88/signature.asc