From roman at kennke.org Fri Sep 5 11:46:03 2008 From: roman at kennke.org (Roman Kennke) Date: Fri, 05 Sep 2008 20:46:03 +0200 Subject: [OpenJDK 2D-Dev] Thoughts about font implementation In-Reply-To: <1218540561.10101.32.camel@moonlight> References: <1218540561.10101.32.camel@moonlight> Message-ID: <1220640363.6422.35.camel@moonlight> Hi there, I'm back from holiday now, and I think Phil is too. I'd like to have another look at this proposal now, it is quite important for me. Any other opinions from you, especially Phil? Cheers, Roman Am Dienstag, den 12.08.2008, 13:29 +0200 schrieb Roman Kennke: > Hi there, > > I have a small problem with current implementation of fonts in OpenJDK. > It is required that fonts are present as files, and that all fonts are > loaded via a FileChannel, not InputStream, because FreeType doesn't > support loading from a sequential-only stream. From my perspective as > embedded VM developer this is not very practical. Ideally I'd like to be > able to embed fonts in the classpath (with the Jamaica VM you can create > a complete image of an application+VM+resources and don't need anything > else on the target machine, sometimes not even a filesystem). I can't do > that using the current approach in OpenJDK. I have some ideas how to > change it, and I think there are also some advantages for the more > general OpenJDK community. Here's my plan which I'd like to discuss: > > - Change TrueTypeFont and all related classes (these are a lot) to read > from a (direct) ByteBuffer, instead of a file channel. FreeType can read > fonts directly from a memory buffer, this would make a lot of code > easier (i.e. freetypeScaler.c wouldn't need these callbacks). > - At a slightly higher level, don't pass FileChannels to TrueTypeFont to > read from, but instead map the file, and pass the resulting buffer. I'm > not sure about all the OS level details, but I think it is possible that > the OS does some interesting optimizations here. For example, if the OS > already has the font file open (for the desktop), this can be reused, > and should be faster than reading into a new buffer. > - File.createFont(InputStream) could be changed to read from the stream > into a memory buffer, instead of a temporary file. > > For me personally, this means that I could access the app+VM+resources > image directly using a (direct) ByteBuffer and pass that to read fonts > from the classpath, thus solving my problem. > > What do you think about this rough outline? Maybe you have other ideas > how to solve my problem? Would such a change have a chance to be > accepted into OpenJDK mainline? (I'd try hard to avoid having to > maintain a fork of the code.) > > Kind regards, Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080905/02e132e3/attachment.bin From roman.kennke at aicas.com Fri Sep 5 11:55:05 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 05 Sep 2008 20:55:05 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() Message-ID: <1220640905.6422.43.camel@moonlight> Hi there, I've just synced up the Cacio forest with the JDK7 master forest, and I'd like to discuss and try to merge back (into JDK7) some of our patches. The following one affects all of AWT, Swing and J2D, this is why I'm posting it to 3 lists at once. In SwingUtilities2.isLocalDisplay(), we have some crazy platform specific code to find if we have a local display or not. This is of course not very nice for other Toolkit implementations than the Win32 and X11 ones in OpenJDK. Our solution is to introduce an abstract method isLocalDisplay() in SunGraphicsEnvironment, which we call from SwingUtilities2. This method is then overridden by the specific GE implementations. If we don't have a SGE, we assume a local display. There are also some changes in the native font code, which used to call the static X11GraphicsEnvironment.isLocalDisplay(), to call the new instance method in SGE. What do you think? Is this reasonable to merge into mainline? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt -------------- next part -------------- # HG changeset patch # User Mario Torre # Date 1217450571 -7200 # Node ID f3ae1241a9b87efec5e22618dcf978ae38c94abd # Parent 9e3c020a78dd72dcbcc8580762f2542055110e2e imported patch j2d-localdisplay.patch diff -r 9e3c020a78dd -r f3ae1241a9b8 src/share/classes/sun/java2d/SunGraphicsEnvironment.java --- a/src/share/classes/sun/java2d/SunGraphicsEnvironment.java Wed Jul 30 22:42:51 2008 +0200 +++ b/src/share/classes/sun/java2d/SunGraphicsEnvironment.java Wed Jul 30 22:42:51 2008 +0200 @@ -1270,6 +1270,13 @@ displayChanger.notifyPaletteChanged(); } + /** + * Returns true when the display is local, false for remote displays. + * + * @return true when the display is local, false for remote displays + */ + public abstract boolean isDisplayLocal(); + /* * ----DISPLAY CHANGE SUPPORT---- */ diff -r 9e3c020a78dd -r f3ae1241a9b8 src/share/classes/sun/swing/SwingUtilities2.java --- a/src/share/classes/sun/swing/SwingUtilities2.java Wed Jul 30 22:42:51 2008 +0200 +++ b/src/share/classes/sun/swing/SwingUtilities2.java Wed Jul 30 22:42:51 2008 +0200 @@ -55,6 +55,7 @@ import java.util.*; import sun.font.FontDesignMetrics; import sun.font.FontManager; +import sun.java2d.SunGraphicsEnvironment; import java.util.concurrent.Callable; import java.util.concurrent.Future; @@ -1482,22 +1483,14 @@ * appear capable of performing gamma correction needed for LCD text. */ public static boolean isLocalDisplay() { - try { - // On Windows just return true. Permission to read os.name - // is granted to all code but wrapped in try to be safe. - if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) { - return true; - } - // Else probably Solaris or Linux in which case may be remote X11 - Class x11Class = Class.forName("sun.awt.X11GraphicsEnvironment"); - Method isDisplayLocalMethod = x11Class.getMethod( - "isDisplayLocal", new Class[0]); - return (Boolean)isDisplayLocalMethod.invoke(null, (Object[])null); - } catch (Throwable t) { + boolean isLocal; + GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); + if (ge instanceof SunGraphicsEnvironment) { + isLocal = ((SunGraphicsEnvironment) ge).isDisplayLocal(); + } else { + isLocal = true; } - // If we get here we're most likely being run on some other O/S - // or we didn't properly detect Windows. - return true; + return isLocal; } /** diff -r 9e3c020a78dd -r f3ae1241a9b8 src/solaris/classes/sun/awt/X11GraphicsEnvironment.java --- a/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Wed Jul 30 22:42:51 2008 +0200 +++ b/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Wed Jul 30 22:42:51 2008 +0200 @@ -208,7 +208,7 @@ private static native int checkShmExt(); private static native String getDisplayString(); - private static Boolean isDisplayLocal; + private Boolean isDisplayLocal; /** * This should only be called from the static initializer, so no need for @@ -233,7 +233,7 @@ return getScreenDevices()[getDefaultScreenNum()]; } - public static boolean isDisplayLocal() { + public boolean isDisplayLocal() { if (isDisplayLocal == null) { SunToolkit.awtLock(); try { diff -r 9e3c020a78dd -r f3ae1241a9b8 src/solaris/native/sun/awt/fontpath.c --- a/src/solaris/native/sun/awt/fontpath.c Wed Jul 30 22:42:51 2008 +0200 +++ b/src/solaris/native/sun/awt/fontpath.c Wed Jul 30 22:42:51 2008 +0200 @@ -150,15 +150,26 @@ static jboolean isLocalSet = False; jboolean ret; - if (isLocalSet) { - return isLocal; + if (! isLocalSet) { + jclass geCls = (*env)->FindClass(env, "java/awt/GraphicsEnvironment"); + jmethodID getLocalGE = (*env)->GetStaticMethodID(env, geCls, + "getLocalGraphicsEnvironment", + "()Ljava/awt/GraphicsEnvironment;"); + jobject ge = (*env)->CallStaticObjectMethod(env, geCls, getLocalGE); + + jclass sgeCls = (*env)->FindClass(env, + "sun/java2d/SunGraphicsEnvironment"); + if ((*env)->IsInstanceOf(env, ge, sgeCls)) { + jmethodID isDisplayLocal = (*env)->GetMethodID(env, sgeCls, + "isDisplayLocal", + "()Z"); + isLocal = (*env)->CallBooleanMethod(env, ge, isDisplayLocal); + } else { + isLocal = True; + } + isLocalSet = True; } - isLocal = JNU_CallStaticMethodByName(env, NULL, - "sun/awt/X11GraphicsEnvironment", - "isDisplayLocal", - "()Z").z; - isLocalSet = True; return isLocal; } diff -r 9e3c020a78dd -r f3ae1241a9b8 src/windows/classes/sun/awt/Win32GraphicsEnvironment.java --- a/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Wed Jul 30 22:42:51 2008 +0200 +++ b/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Wed Jul 30 22:42:51 2008 +0200 @@ -346,4 +346,8 @@ return new WFontConfiguration(this, preferLocaleFonts,preferPropFonts); } + + public boolean isDisplayLocal() { + return true; + } } From Dmitri.Trembovetski at Sun.COM Fri Sep 5 13:25:25 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 05 Sep 2008 13:25:25 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <1220640905.6422.43.camel@moonlight> References: <1220640905.6422.43.camel@moonlight> Message-ID: <48C195B5.2010205@Sun.COM> Hi Roman, the patch looks reasonable to me. Thanks, Dmitri Roman Kennke wrote: > Hi there, > > I've just synced up the Cacio forest with the JDK7 master forest, and > I'd like to discuss and try to merge back (into JDK7) some of our > patches. The following one affects all of AWT, Swing and J2D, this is > why I'm posting it to 3 lists at once. > > In SwingUtilities2.isLocalDisplay(), we have some crazy platform > specific code to find if we have a local display or not. This is of > course not very nice for other Toolkit implementations than the Win32 > and X11 ones in OpenJDK. Our solution is to introduce an abstract method > isLocalDisplay() in SunGraphicsEnvironment, which we call from > SwingUtilities2. This method is then overridden by the specific GE > implementations. If we don't have a SGE, we assume a local display. > > There are also some changes in the native font code, which used to call > the static X11GraphicsEnvironment.isLocalDisplay(), to call the new > instance method in SGE. > > What do you think? Is this reasonable to merge into mainline? > > /Roman > > From roman.kennke at aicas.com Sat Sep 6 02:04:01 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Sat, 06 Sep 2008 11:04:01 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> Message-ID: <1220691841.6571.22.camel@moonlight> Hi Oleg, > I'm not the person who is supposed to review this changes from > technical point of view, > but I have one concern about idea of the fix. It adds one more place > where Swing uses sun-specific API. No. It takes advantage of Sun internal API, but it does not depend on it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } else { useReasonableDefault(); } ). > Of course you can say that SwingUtilities2.isLocalDisplay() even > before your fix uses code which is specific > for Sun's implementation, and you will be right. But this doesn't > mean that we should leave with this. > IMHO, if we change such code we should remove dependency between Swing > and Sun-specific code, > i.e. we should add public API. I completely agree. That, of course, would be the best solution. But in the past it has been communicated several times to me that I can't just send in patches to public API and hope that it will be accepted easily. I propose to get in this patch if possible first, then start a discussion about adding public API. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From roman.kennke at aicas.com Mon Sep 8 12:04:33 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Mon, 08 Sep 2008 21:04:33 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> Message-ID: <1220900673.7112.25.camel@moonlight> Hi Oleg and lists, > >> I'm not the person who is supposed to review this changes from > >> technical point of view, > >> but I have one concern about idea of the fix. It adds one more place > >> where Swing uses sun-specific API. > > > > No. It takes advantage of Sun internal API, but it does not depend on > > it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } > > else { useReasonableDefault(); } ). > > it uses Sun-specific class, so this code can not be compiled by JDK > from another vendor :( Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! (Ok, the Caciocavallo project will certainly help alot, but we are still very far away from such a portable Swing). > >> Of course you can say that SwingUtilities2.isLocalDisplay() even > >> before your fix uses code which is specific > >> for Sun's implementation, and you will be right. But this doesn't > >> mean that we should leave with this. > >> IMHO, if we change such code we should remove dependency between Swing > >> and Sun-specific code, > >> i.e. we should add public API. > > > > I completely agree. That, of course, would be the best solution. But in > > the past it has been communicated several times to me that I can't just > > send in patches to public API and hope that it will be accepted easily. > > I propose to get in this patch if possible first, then start a > > discussion about adding public API. > > I understand your point, but I have a feeling that we you will not > start the discussion right now, > the idea of new API may be lost :( So, I'd suggest to try one more time ;) Ok, so here we go. This patch is slightly modified, the isDisplayLocal() method is now declared in GraphicsEnvironment, with the addition of throwing a HeadlessException in the headless case. Also, in fontpath.c, we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We call it on X11GraphicsEnvironment only. In my original patch I tried to be more portable by calling GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but this resulted in an initialization loop (this code is very sensible to this kind of problem). I left that out for now, because fontpath.c is X11 specific anyway, and a real solution will come soon in the form of a huge FontManager patch :-) What do you think? Can we add this API to GE? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From roman.kennke at aicas.com Mon Sep 8 12:11:14 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Mon, 08 Sep 2008 21:11:14 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <1220900673.7112.25.camel@moonlight> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> Message-ID: <1220901074.7112.27.camel@moonlight> Bah, forgot the actual patch. Here it comes now! /Roman Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: > Hi Oleg and lists, > > > >> I'm not the person who is supposed to review this changes from > > >> technical point of view, > > >> but I have one concern about idea of the fix. It adds one more place > > >> where Swing uses sun-specific API. > > > > > > No. It takes advantage of Sun internal API, but it does not depend on > > > it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } > > > else { useReasonableDefault(); } ). > > > > it uses Sun-specific class, so this code can not be compiled by JDK > > from another vendor :( > > Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! > (Ok, the Caciocavallo project will certainly help alot, but we are still > very far away from such a portable Swing). > > > >> Of course you can say that SwingUtilities2.isLocalDisplay() even > > >> before your fix uses code which is specific > > >> for Sun's implementation, and you will be right. But this doesn't > > >> mean that we should leave with this. > > >> IMHO, if we change such code we should remove dependency between Swing > > >> and Sun-specific code, > > >> i.e. we should add public API. > > > > > > I completely agree. That, of course, would be the best solution. But in > > > the past it has been communicated several times to me that I can't just > > > send in patches to public API and hope that it will be accepted easily. > > > I propose to get in this patch if possible first, then start a > > > discussion about adding public API. > > > > I understand your point, but I have a feeling that we you will not > > start the discussion right now, > > the idea of new API may be lost :( So, I'd suggest to try one more time ;) > > Ok, so here we go. This patch is slightly modified, the isDisplayLocal() > method is now declared in GraphicsEnvironment, with the addition of > throwing a HeadlessException in the headless case. Also, in fontpath.c, > we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We > call it on X11GraphicsEnvironment only. In my original patch I tried to > be more portable by calling > GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but > this resulted in an initialization loop (this code is very sensible to > this kind of problem). I left that out for now, because fontpath.c is > X11 specific anyway, and a real solution will come soon in the form of a > huge FontManager patch :-) > > What do you think? Can we add this API to GE? > > /Roman > -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.txt Type: text/x-patch Size: 4808 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080908/8cfaf878/patch.txt From son.two at gmail.com Mon Sep 8 20:26:46 2008 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Tue, 9 Sep 2008 07:26:46 +0400 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <1220901074.7112.27.camel@moonlight> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> Message-ID: <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> I'd vote for this API, but it is 2D team who should make the decision. Oleg. On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke wrote: > Bah, forgot the actual patch. Here it comes now! > > /Roman > > Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: >> Hi Oleg and lists, >> >> > >> I'm not the person who is supposed to review this changes from >> > >> technical point of view, >> > >> but I have one concern about idea of the fix. It adds one more place >> > >> where Swing uses sun-specific API. >> > > >> > > No. It takes advantage of Sun internal API, but it does not depend on >> > > it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } >> > > else { useReasonableDefault(); } ). >> > >> > it uses Sun-specific class, so this code can not be compiled by JDK >> > from another vendor :( >> >> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! >> (Ok, the Caciocavallo project will certainly help alot, but we are still >> very far away from such a portable Swing). >> >> > >> Of course you can say that SwingUtilities2.isLocalDisplay() even >> > >> before your fix uses code which is specific >> > >> for Sun's implementation, and you will be right. But this doesn't >> > >> mean that we should leave with this. >> > >> IMHO, if we change such code we should remove dependency between Swing >> > >> and Sun-specific code, >> > >> i.e. we should add public API. >> > > >> > > I completely agree. That, of course, would be the best solution. But in >> > > the past it has been communicated several times to me that I can't just >> > > send in patches to public API and hope that it will be accepted easily. >> > > I propose to get in this patch if possible first, then start a >> > > discussion about adding public API. >> > >> > I understand your point, but I have a feeling that we you will not >> > start the discussion right now, >> > the idea of new API may be lost :( So, I'd suggest to try one more time ;) >> >> Ok, so here we go. This patch is slightly modified, the isDisplayLocal() >> method is now declared in GraphicsEnvironment, with the addition of >> throwing a HeadlessException in the headless case. Also, in fontpath.c, >> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We >> call it on X11GraphicsEnvironment only. In my original patch I tried to >> be more portable by calling >> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but >> this resulted in an initialization loop (this code is very sensible to >> this kind of problem). I left that out for now, because fontpath.c is >> X11 specific anyway, and a real solution will come soon in the form of a >> huge FontManager patch :-) >> >> What do you think? Can we add this API to GE? >> >> /Roman >> > -- > Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org > aicas Allerton Interworks Computer Automated Systems GmbH > Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany > http://www.aicas.com * Tel: +49-721-663 968-48 > USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe > Gesch?ftsf?hrer: Dr. James J. Hunt > From Dmitri.Trembovetski at Sun.COM Tue Sep 9 11:16:20 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 09 Sep 2008 11:16:20 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> Message-ID: <48C6BD74.1070705@Sun.COM> Hi Oleg, Roman, I myself don't think that this API belongs in public. It is used by the platform implementation for doing specific tasks and is of questionable value for general public. Also, it is too platform-specific and typically we refrain from adding platform-specific APIs to the Java platform. How do you think the developers would use it anyway? Those developers who know what a "remote display" is - which I assume is a minority since most developers never leave the Windows world - can detect it themselves if they really needed something like this - it's not a big deal, just read the DISPLAY env. variable and figure it out. In the specific case of SwingUtilities I believe they only use it to determine whether to enable AA text or not. So perhaps that's something that should be exposed instead. And talking about implementation - if we were to add something to this effect to the platform, we'd need to go all the way and possibly detect remote desktop session on Windows as well. And what about VNC sessions? In our current implementation we only care about "remote X display" situation, but the developers who see this public API could assume otherwise. I suggest to fall back to the original Roman's patch which just exposed this method in SunGraphicsEnvironment. Thanks, Dmitri Oleg Sukhodolsky wrote: > I'd vote for this API, but it is 2D team who should make the decision. > > Oleg. > > On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke wrote: >> Bah, forgot the actual patch. Here it comes now! >> >> /Roman >> >> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: >>> Hi Oleg and lists, >>> >>>>>> I'm not the person who is supposed to review this changes from >>>>>> technical point of view, >>>>>> but I have one concern about idea of the fix. It adds one more place >>>>>> where Swing uses sun-specific API. >>>>> No. It takes advantage of Sun internal API, but it does not depend on >>>>> it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } >>>>> else { useReasonableDefault(); } ). >>>> it uses Sun-specific class, so this code can not be compiled by JDK >>>> from another vendor :( >>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! >>> (Ok, the Caciocavallo project will certainly help alot, but we are still >>> very far away from such a portable Swing). >>> >>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even >>>>>> before your fix uses code which is specific >>>>>> for Sun's implementation, and you will be right. But this doesn't >>>>>> mean that we should leave with this. >>>>>> IMHO, if we change such code we should remove dependency between Swing >>>>>> and Sun-specific code, >>>>>> i.e. we should add public API. >>>>> I completely agree. That, of course, would be the best solution. But in >>>>> the past it has been communicated several times to me that I can't just >>>>> send in patches to public API and hope that it will be accepted easily. >>>>> I propose to get in this patch if possible first, then start a >>>>> discussion about adding public API. >>>> I understand your point, but I have a feeling that we you will not >>>> start the discussion right now, >>>> the idea of new API may be lost :( So, I'd suggest to try one more time ;) >>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal() >>> method is now declared in GraphicsEnvironment, with the addition of >>> throwing a HeadlessException in the headless case. Also, in fontpath.c, >>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We >>> call it on X11GraphicsEnvironment only. In my original patch I tried to >>> be more portable by calling >>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but >>> this resulted in an initialization loop (this code is very sensible to >>> this kind of problem). I left that out for now, because fontpath.c is >>> X11 specific anyway, and a real solution will come soon in the form of a >>> huge FontManager patch :-) >>> >>> What do you think? Can we add this API to GE? >>> >>> /Roman >>> >> -- >> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org >> aicas Allerton Interworks Computer Automated Systems GmbH >> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany >> http://www.aicas.com * Tel: +49-721-663 968-48 >> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe >> Gesch?ftsf?hrer: Dr. James J. Hunt >> From martinrb at google.com Tue Sep 9 13:09:13 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 9 Sep 2008 13:09:13 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <48C6BD74.1070705@Sun.COM> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> Message-ID: <1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com> It's very hard to get these kinds of UI issues right. I once tried to configure my xemacs to have less eye candy when talking to a "slow" X server by actually timing some operation that requires a round trip. Note that a method like isLocalDisplay would have the wrong semantics for me, because I mostly cared about whether I was bottlenecked by VPN. This did help me get my work done, but this kind of timing-dependent behavior is disconcerting to the user, especially if they feel they have no control or do not understand the behavior. It "looks like a bug". Will FAQs and bug reports appear Q: Sometimes my java app starts up with funky fonts. A: Try restarting a few times in a loop, or try setting this magic system property: Martin On Tue, Sep 9, 2008 at 11:16, Dmitri Trembovetski wrote: > > Hi Oleg, Roman, > > I myself don't think that this API belongs in public. > > It is used by the platform implementation for doing > specific tasks and is of questionable value for > general public. Also, it is too platform-specific > and typically we refrain from adding platform-specific > APIs to the Java platform. > > How do you think the developers would use it anyway? > > Those developers who know what a "remote display" is - > which I assume is a minority since most developers never > leave the Windows world - can detect it themselves if > they really needed something like this - it's not a > big deal, just read the DISPLAY env. variable and > figure it out. > > In the specific case of SwingUtilities I believe they > only use it to determine whether to enable AA text > or not. So perhaps that's something that should > be exposed instead. > > And talking about implementation - if we were to add > something to this effect to the platform, we'd need > to go all the way and possibly detect remote desktop > session on Windows as well. And what about VNC sessions? > In our current implementation we only care about > "remote X display" situation, but the developers who > see this public API could assume otherwise. > > I suggest to fall back to the original Roman's > patch which just exposed this method in > SunGraphicsEnvironment. > > Thanks, > Dmitri > > Oleg Sukhodolsky wrote: >> >> I'd vote for this API, but it is 2D team who should make the decision. >> >> Oleg. >> >> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke >> wrote: >>> >>> Bah, forgot the actual patch. Here it comes now! >>> >>> /Roman >>> >>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: >>>> >>>> Hi Oleg and lists, >>>> >>>>>>> I'm not the person who is supposed to review this changes from >>>>>>> technical point of view, >>>>>>> but I have one concern about idea of the fix. It adds one more place >>>>>>> where Swing uses sun-specific API. >>>>>> >>>>>> No. It takes advantage of Sun internal API, but it does not depend on >>>>>> it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } >>>>>> else { useReasonableDefault(); } ). >>>>> >>>>> it uses Sun-specific class, so this code can not be compiled by JDK >>>>> from another vendor :( >>>> >>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! >>>> (Ok, the Caciocavallo project will certainly help alot, but we are still >>>> very far away from such a portable Swing). >>>> >>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even >>>>>>> before your fix uses code which is specific >>>>>>> for Sun's implementation, and you will be right. But this doesn't >>>>>>> mean that we should leave with this. >>>>>>> IMHO, if we change such code we should remove dependency between >>>>>>> Swing >>>>>>> and Sun-specific code, >>>>>>> i.e. we should add public API. >>>>>> >>>>>> I completely agree. That, of course, would be the best solution. But >>>>>> in >>>>>> the past it has been communicated several times to me that I can't >>>>>> just >>>>>> send in patches to public API and hope that it will be accepted >>>>>> easily. >>>>>> I propose to get in this patch if possible first, then start a >>>>>> discussion about adding public API. >>>>> >>>>> I understand your point, but I have a feeling that we you will not >>>>> start the discussion right now, >>>>> the idea of new API may be lost :( So, I'd suggest to try one more >>>>> time ;) >>>> >>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal() >>>> method is now declared in GraphicsEnvironment, with the addition of >>>> throwing a HeadlessException in the headless case. Also, in fontpath.c, >>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We >>>> call it on X11GraphicsEnvironment only. In my original patch I tried to >>>> be more portable by calling >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but >>>> this resulted in an initialization loop (this code is very sensible to >>>> this kind of problem). I left that out for now, because fontpath.c is >>>> X11 specific anyway, and a real solution will come soon in the form of a >>>> huge FontManager patch :-) >>>> >>>> What do you think? Can we add this API to GE? >>>> >>>> /Roman >>>> >>> -- >>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org >>> aicas Allerton Interworks Computer Automated Systems GmbH >>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany >>> http://www.aicas.com * Tel: +49-721-663 968-48 >>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe >>> Gesch?ftsf?hrer: Dr. James J. Hunt >>> > From Dmitri.Trembovetski at Sun.COM Tue Sep 9 15:12:03 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 09 Sep 2008 15:12:03 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com> Message-ID: <48C6F4B3.50506@Sun.COM> Martin Buchholz wrote: > It's very hard to get these kinds of UI issues right. > > I once tried to configure my xemacs to have less eye candy > when talking to a "slow" X server by actually timing > some operation that requires a round trip. > > Note that a method like isLocalDisplay would have the > wrong semantics for me, because I mostly cared about > whether I was bottlenecked by VPN. > > This did help me get my work done, but this kind of > timing-dependent behavior is disconcerting to the user, > especially if they feel they have no control or do not > understand the behavior. It "looks like a bug". > > Will FAQs and bug reports appear > Q: Sometimes my java app starts up with funky fonts. > A: Try restarting a few times in a loop, or try setting this magic > system property: http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gdlvo.html#gdlwn Thanks, Dmitri > > Martin > > On Tue, Sep 9, 2008 at 11:16, Dmitri Trembovetski > wrote: >> Hi Oleg, Roman, >> >> I myself don't think that this API belongs in public. >> >> It is used by the platform implementation for doing >> specific tasks and is of questionable value for >> general public. Also, it is too platform-specific >> and typically we refrain from adding platform-specific >> APIs to the Java platform. >> >> How do you think the developers would use it anyway? >> >> Those developers who know what a "remote display" is - >> which I assume is a minority since most developers never >> leave the Windows world - can detect it themselves if >> they really needed something like this - it's not a >> big deal, just read the DISPLAY env. variable and >> figure it out. >> >> In the specific case of SwingUtilities I believe they >> only use it to determine whether to enable AA text >> or not. So perhaps that's something that should >> be exposed instead. >> >> And talking about implementation - if we were to add >> something to this effect to the platform, we'd need >> to go all the way and possibly detect remote desktop >> session on Windows as well. And what about VNC sessions? >> In our current implementation we only care about >> "remote X display" situation, but the developers who >> see this public API could assume otherwise. >> >> I suggest to fall back to the original Roman's >> patch which just exposed this method in >> SunGraphicsEnvironment. >> >> Thanks, >> Dmitri >> >> Oleg Sukhodolsky wrote: >>> I'd vote for this API, but it is 2D team who should make the decision. >>> >>> Oleg. >>> >>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke >>> wrote: >>>> Bah, forgot the actual patch. Here it comes now! >>>> >>>> /Roman >>>> >>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: >>>>> Hi Oleg and lists, >>>>> >>>>>>>> I'm not the person who is supposed to review this changes from >>>>>>>> technical point of view, >>>>>>>> but I have one concern about idea of the fix. It adds one more place >>>>>>>> where Swing uses sun-specific API. >>>>>>> No. It takes advantage of Sun internal API, but it does not depend on >>>>>>> it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } >>>>>>> else { useReasonableDefault(); } ). >>>>>> it uses Sun-specific class, so this code can not be compiled by JDK >>>>>> from another vendor :( >>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! >>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still >>>>> very far away from such a portable Swing). >>>>> >>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even >>>>>>>> before your fix uses code which is specific >>>>>>>> for Sun's implementation, and you will be right. But this doesn't >>>>>>>> mean that we should leave with this. >>>>>>>> IMHO, if we change such code we should remove dependency between >>>>>>>> Swing >>>>>>>> and Sun-specific code, >>>>>>>> i.e. we should add public API. >>>>>>> I completely agree. That, of course, would be the best solution. But >>>>>>> in >>>>>>> the past it has been communicated several times to me that I can't >>>>>>> just >>>>>>> send in patches to public API and hope that it will be accepted >>>>>>> easily. >>>>>>> I propose to get in this patch if possible first, then start a >>>>>>> discussion about adding public API. >>>>>> I understand your point, but I have a feeling that we you will not >>>>>> start the discussion right now, >>>>>> the idea of new API may be lost :( So, I'd suggest to try one more >>>>>> time ;) >>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal() >>>>> method is now declared in GraphicsEnvironment, with the addition of >>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c, >>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We >>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to >>>>> be more portable by calling >>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but >>>>> this resulted in an initialization loop (this code is very sensible to >>>>> this kind of problem). I left that out for now, because fontpath.c is >>>>> X11 specific anyway, and a real solution will come soon in the form of a >>>>> huge FontManager patch :-) >>>>> >>>>> What do you think? Can we add this API to GE? >>>>> >>>>> /Roman >>>>> >>>> -- >>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org >>>> aicas Allerton Interworks Computer Automated Systems GmbH >>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany >>>> http://www.aicas.com * Tel: +49-721-663 968-48 >>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe >>>> Gesch?ftsf?hrer: Dr. James J. Hunt >>>> From son.two at gmail.com Tue Sep 9 20:40:29 2008 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Wed, 10 Sep 2008 07:40:29 +0400 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <48C6BD74.1070705@Sun.COM> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> Message-ID: <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> Hi Dmitri, I understand than you do not want to add questionable code in 2D, but I do not like the idea to make this by adding questionable code to Swing. So before falliwing back to hack I'd suggest to thinkabout possible API, otherwise we have a good chance to keep this hack in Swing code forever :( Oleg. On Tue, Sep 9, 2008 at 10:16 PM, Dmitri Trembovetski wrote: > > Hi Oleg, Roman, > > I myself don't think that this API belongs in public. > > It is used by the platform implementation for doing > specific tasks and is of questionable value for > general public. Also, it is too platform-specific > and typically we refrain from adding platform-specific > APIs to the Java platform. > > How do you think the developers would use it anyway? > > Those developers who know what a "remote display" is - > which I assume is a minority since most developers never > leave the Windows world - can detect it themselves if > they really needed something like this - it's not a > big deal, just read the DISPLAY env. variable and > figure it out. > > In the specific case of SwingUtilities I believe they > only use it to determine whether to enable AA text > or not. So perhaps that's something that should > be exposed instead. > > And talking about implementation - if we were to add > something to this effect to the platform, we'd need > to go all the way and possibly detect remote desktop > session on Windows as well. And what about VNC sessions? > In our current implementation we only care about > "remote X display" situation, but the developers who > see this public API could assume otherwise. > > I suggest to fall back to the original Roman's > patch which just exposed this method in > SunGraphicsEnvironment. > > Thanks, > Dmitri > > Oleg Sukhodolsky wrote: >> >> I'd vote for this API, but it is 2D team who should make the decision. >> >> Oleg. >> >> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke >> wrote: >>> >>> Bah, forgot the actual patch. Here it comes now! >>> >>> /Roman >>> >>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: >>>> >>>> Hi Oleg and lists, >>>> >>>>>>> I'm not the person who is supposed to review this changes from >>>>>>> technical point of view, >>>>>>> but I have one concern about idea of the fix. It adds one more place >>>>>>> where Swing uses sun-specific API. >>>>>> >>>>>> No. It takes advantage of Sun internal API, but it does not depend on >>>>>> it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } >>>>>> else { useReasonableDefault(); } ). >>>>> >>>>> it uses Sun-specific class, so this code can not be compiled by JDK >>>>> from another vendor :( >>>> >>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! >>>> (Ok, the Caciocavallo project will certainly help alot, but we are still >>>> very far away from such a portable Swing). >>>> >>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even >>>>>>> before your fix uses code which is specific >>>>>>> for Sun's implementation, and you will be right. But this doesn't >>>>>>> mean that we should leave with this. >>>>>>> IMHO, if we change such code we should remove dependency between >>>>>>> Swing >>>>>>> and Sun-specific code, >>>>>>> i.e. we should add public API. >>>>>> >>>>>> I completely agree. That, of course, would be the best solution. But >>>>>> in >>>>>> the past it has been communicated several times to me that I can't >>>>>> just >>>>>> send in patches to public API and hope that it will be accepted >>>>>> easily. >>>>>> I propose to get in this patch if possible first, then start a >>>>>> discussion about adding public API. >>>>> >>>>> I understand your point, but I have a feeling that we you will not >>>>> start the discussion right now, >>>>> the idea of new API may be lost :( So, I'd suggest to try one more >>>>> time ;) >>>> >>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal() >>>> method is now declared in GraphicsEnvironment, with the addition of >>>> throwing a HeadlessException in the headless case. Also, in fontpath.c, >>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We >>>> call it on X11GraphicsEnvironment only. In my original patch I tried to >>>> be more portable by calling >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but >>>> this resulted in an initialization loop (this code is very sensible to >>>> this kind of problem). I left that out for now, because fontpath.c is >>>> X11 specific anyway, and a real solution will come soon in the form of a >>>> huge FontManager patch :-) >>>> >>>> What do you think? Can we add this API to GE? >>>> >>>> /Roman >>>> >>> -- >>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org >>> aicas Allerton Interworks Computer Automated Systems GmbH >>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany >>> http://www.aicas.com * Tel: +49-721-663 968-48 >>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe >>> Gesch?ftsf?hrer: Dr. James J. Hunt >>> > From Dmitri.Trembovetski at Sun.COM Wed Sep 10 09:19:51 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 10 Sep 2008 09:19:51 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> Message-ID: <48C7F3A7.6010803@Sun.COM> Hi Oleg, Oleg Sukhodolsky wrote: > I understand than you do not want to add questionable code in 2D, > but I do not like the idea to make this by adding questionable code > to Swing. So before falliwing back to hack I'd suggest to thinkabout I'm not sure what you mean by "adding questionable code to Swing" - the code was already there. Now instead of directly calling sun internal API it will call a better defined internal API. > possible API, otherwise we have a good chance to keep this hack > in Swing code forever :( Swing is part of the platform, and will always have to use some APIs in the implementation which are not available to external developers. I don't see a problem with that. In this particular case I really don't see any benefit in exposing this very platform-specific API to the developers. Thanks, Dmitri > > Oleg. > > On Tue, Sep 9, 2008 at 10:16 PM, Dmitri Trembovetski > wrote: >> Hi Oleg, Roman, >> >> I myself don't think that this API belongs in public. >> >> It is used by the platform implementation for doing >> specific tasks and is of questionable value for >> general public. Also, it is too platform-specific >> and typically we refrain from adding platform-specific >> APIs to the Java platform. >> >> How do you think the developers would use it anyway? >> >> Those developers who know what a "remote display" is - >> which I assume is a minority since most developers never >> leave the Windows world - can detect it themselves if >> they really needed something like this - it's not a >> big deal, just read the DISPLAY env. variable and >> figure it out. >> >> In the specific case of SwingUtilities I believe they >> only use it to determine whether to enable AA text >> or not. So perhaps that's something that should >> be exposed instead. >> >> And talking about implementation - if we were to add >> something to this effect to the platform, we'd need >> to go all the way and possibly detect remote desktop >> session on Windows as well. And what about VNC sessions? >> In our current implementation we only care about >> "remote X display" situation, but the developers who >> see this public API could assume otherwise. >> >> I suggest to fall back to the original Roman's >> patch which just exposed this method in >> SunGraphicsEnvironment. >> >> Thanks, >> Dmitri >> >> Oleg Sukhodolsky wrote: >>> I'd vote for this API, but it is 2D team who should make the decision. >>> >>> Oleg. >>> >>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke >>> wrote: >>>> Bah, forgot the actual patch. Here it comes now! >>>> >>>> /Roman >>>> >>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: >>>>> Hi Oleg and lists, >>>>> >>>>>>>> I'm not the person who is supposed to review this changes from >>>>>>>> technical point of view, >>>>>>>> but I have one concern about idea of the fix. It adds one more place >>>>>>>> where Swing uses sun-specific API. >>>>>>> No. It takes advantage of Sun internal API, but it does not depend on >>>>>>> it. (if (ge instanceof SunGraphicsEnvironment) { doSomethingCool(); } >>>>>>> else { useReasonableDefault(); } ). >>>>>> it uses Sun-specific class, so this code can not be compiled by JDK >>>>>> from another vendor :( >>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck! >>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still >>>>> very far away from such a portable Swing). >>>>> >>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even >>>>>>>> before your fix uses code which is specific >>>>>>>> for Sun's implementation, and you will be right. But this doesn't >>>>>>>> mean that we should leave with this. >>>>>>>> IMHO, if we change such code we should remove dependency between >>>>>>>> Swing >>>>>>>> and Sun-specific code, >>>>>>>> i.e. we should add public API. >>>>>>> I completely agree. That, of course, would be the best solution. But >>>>>>> in >>>>>>> the past it has been communicated several times to me that I can't >>>>>>> just >>>>>>> send in patches to public API and hope that it will be accepted >>>>>>> easily. >>>>>>> I propose to get in this patch if possible first, then start a >>>>>>> discussion about adding public API. >>>>>> I understand your point, but I have a feeling that we you will not >>>>>> start the discussion right now, >>>>>> the idea of new API may be lost :( So, I'd suggest to try one more >>>>>> time ;) >>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal() >>>>> method is now declared in GraphicsEnvironment, with the addition of >>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c, >>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We >>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to >>>>> be more portable by calling >>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but >>>>> this resulted in an initialization loop (this code is very sensible to >>>>> this kind of problem). I left that out for now, because fontpath.c is >>>>> X11 specific anyway, and a real solution will come soon in the form of a >>>>> huge FontManager patch :-) >>>>> >>>>> What do you think? Can we add this API to GE? >>>>> >>>>> /Roman >>>>> >>>> -- >>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org >>>> aicas Allerton Interworks Computer Automated Systems GmbH >>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany >>>> http://www.aicas.com * Tel: +49-721-663 968-48 >>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe >>>> Gesch?ftsf?hrer: Dr. James J. Hunt >>>> From roman.kennke at aicas.com Wed Sep 10 12:04:31 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 10 Sep 2008 21:04:31 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <48C7F3A7.6010803@Sun.COM> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> <48C7F3A7.6010803@Sun.COM> Message-ID: <1221073471.6592.27.camel@moonlight> Hi Dmitri and Oleg, > > I understand than you do not want to add questionable code in 2D, > > but I do not like the idea to make this by adding questionable code > > to Swing. So before falliwing back to hack I'd suggest to thinkabout > > I'm not sure what you mean by "adding questionable code > to Swing" - the code was already there. Now instead of > directly calling sun internal API it will call a better > defined internal API. Yeah, I agree. > > possible API, otherwise we have a good chance to keep this hack > > in Swing code forever :( > > Swing is part of the platform, and will always have to > use some APIs in the implementation which are not available > to external developers. > > I don't see a problem with that. In this particular case > I really don't see any benefit in exposing this very > platform-specific API to the developers. Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2 anyway, so this is more or less the porting interface for Swing for people who really need to port OpenJDK Swing to a different JDK. If it is a goal to support that, it might make sense to find all remaining uses of Sun-specific code in Swing and refactor that to also use SwingUtilities2. Or even better, create a separate interface and factory for implementations of that interface that would be provided by the developer who ports Swing. But that seems a little over the top right now. I also suggest to get the original patch through. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From roman at kennke.org Wed Sep 10 14:54:34 2008 From: roman at kennke.org (Roman Kennke) Date: Wed, 10 Sep 2008 23:54:34 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <1221073471.6592.27.camel@moonlight> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> <48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight> Message-ID: <1221083674.6592.35.camel@moonlight> I need to repost my original patch for two reasons: 1. it doesn't apply cleanly (only with some fuzz), 2. it also has this init-loop problem. Find attached the correct version. I'd be happy to see it committed ASAP. /Roman Am Mittwoch, den 10.09.2008, 21:04 +0200 schrieb Roman Kennke: > Hi Dmitri and Oleg, > > > > I understand than you do not want to add questionable code in 2D, > > > but I do not like the idea to make this by adding questionable code > > > to Swing. So before falliwing back to hack I'd suggest to thinkabout > > > > I'm not sure what you mean by "adding questionable code > > to Swing" - the code was already there. Now instead of > > directly calling sun internal API it will call a better > > defined internal API. > > Yeah, I agree. > > > > possible API, otherwise we have a good chance to keep this hack > > > in Swing code forever :( > > > > Swing is part of the platform, and will always have to > > use some APIs in the implementation which are not available > > to external developers. > > > > I don't see a problem with that. In this particular case > > I really don't see any benefit in exposing this very > > platform-specific API to the developers. > > Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2 > anyway, so this is more or less the porting interface for Swing for > people who really need to port OpenJDK Swing to a different JDK. If it > is a goal to support that, it might make sense to find all remaining > uses of Sun-specific code in Swing and refactor that to also use > SwingUtilities2. Or even better, create a separate interface and factory > for implementations of that interface that would be provided by the > developer who ports Swing. But that seems a little over the top right > now. I also suggest to get the original patch through. > > /Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.txt Type: text/x-patch Size: 4368 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080910/be736a0a/patch.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080910/be736a0a/attachment.bin From linuxhippy at gmail.com Wed Sep 10 15:30:12 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 11 Sep 2008 00:30:12 +0200 Subject: [OpenJDK 2D-Dev] Delivering more information about Mask-Operations to the pipelines? Message-ID: <194f62550809101530vdee73f1t1b2354f2f705e17b@mail.gmail.com> Hello, I have some ideas about tuning antialiased rendering of my pipeline, because the current approach (XPutImage of alpha-data to pixmap) has some performance drawbacks. The problems are: - The pipeline uses XPutImage, even if SHM is available - forcing image data over (local) sockets. This however has the advantage of not having to XSync. - XLib based on XCB uses a 4kb buffer, so after only a few alpha-tiles (4-10), the buffer is flushed. I see a high context-switch rate (15.000cs/s) when running the line-anim demo in antialiased mode. - Composition of small tiles (32x32 and smaller) is quite slow because of high-primitive overhead (this hopefully will change soon, can't do much about that) I cannot simply switch to SHM because that would (as far as I have understand) require synchronization with the X-Server. I did some benchmarks using SHM and performance was a lot worse than without, because the advantage of not having to copy image data was completly invalidated by the cost of the round-tip. SHM could be an advantage, used like this: - Allocate a large number of alpha-tile size pixmaps (128 or even more) - Fill those alpha tiles one after another without syncing - Sync and composite when the mask-fill operation is done. Depending on the values it could be decided wether using SHM would be beneficial (e.g. large antialiased shapes), or wether using XPutImage would be better. However this would require some more information from the tile generator, like the number of total tiles and number of total tiles This information could be devlivered to the pipeline either through MaskFill/MaskBlit methods for every tile, or with an initialization method like initMaskBlit. Maybe a bit more advanced would be the possibility of buffering MaskFills/MaskBlits until those 128+ alpha pixmaps are all used and only flush when really needed, but I don't know how this could be implemented. I guess a fair amount of tracking would be needed to make that possible. Do you think passing down more information from the Tile-Generators could be a bad idea? Do you think other pipelines could benefit from such optimizations too? How important is good AA performance considered? Thank you in advance, Clemens From Dmitri.Trembovetski at Sun.COM Wed Sep 10 15:45:04 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 10 Sep 2008 15:45:04 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <1221083674.6592.35.camel@moonlight> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> <48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight> <1221083674.6592.35.camel@moonlight> Message-ID: <48C84DF0.1090506@Sun.COM> Roman Kennke wrote: > I need to repost my original patch for two reasons: 1. it doesn't apply > cleanly (only with some fuzz), 2. it also has this init-loop problem. > Find attached the correct version. I'd be happy to see it committed > ASAP. I have a question about the fix: --- a/src/solaris/native/sun/awt/fontpath.c Thu Aug 07 09:42:31 2008 -0700 +++ b/src/solaris/native/sun/awt/fontpath.c Wed Sep 10 23:52:15 2008 +0200 @@ -156,7 +156,7 @@ isLocal = JNU_CallStaticMethodByName(env, NULL, "sun/awt/X11GraphicsEnvironment", - "isDisplayLocal", + "_isDisplayLocal", "()Z").z; Didn't you change isDisplayLocal to be non-static in X11GraphicsEnvironment? If so how does this actually work since you still call CallStaticMethodByName? Thanks, Dmitri > > /Roman > > Am Mittwoch, den 10.09.2008, 21:04 +0200 schrieb Roman Kennke: >> Hi Dmitri and Oleg, >> >>>> I understand than you do not want to add questionable code in 2D, >>>> but I do not like the idea to make this by adding questionable code >>>> to Swing. So before falliwing back to hack I'd suggest to thinkabout >>> I'm not sure what you mean by "adding questionable code >>> to Swing" - the code was already there. Now instead of >>> directly calling sun internal API it will call a better >>> defined internal API. >> Yeah, I agree. >> >>>> possible API, otherwise we have a good chance to keep this hack >>>> in Swing code forever :( >>> Swing is part of the platform, and will always have to >>> use some APIs in the implementation which are not available >>> to external developers. >>> >>> I don't see a problem with that. In this particular case >>> I really don't see any benefit in exposing this very >>> platform-specific API to the developers. >> Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2 >> anyway, so this is more or less the porting interface for Swing for >> people who really need to port OpenJDK Swing to a different JDK. If it >> is a goal to support that, it might make sense to find all remaining >> uses of Sun-specific code in Swing and refactor that to also use >> SwingUtilities2. Or even better, create a separate interface and factory >> for implementations of that interface that would be provided by the >> developer who ports Swing. But that seems a little over the top right >> now. I also suggest to get the original patch through. >> >> /Roman From mario.torre at aicas.com Wed Sep 10 16:15:54 2008 From: mario.torre at aicas.com (Mario Torre) Date: Thu, 11 Sep 2008 01:15:54 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <48C84DF0.1090506@Sun.COM> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> <48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight> <1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM> Message-ID: <1221088554.3336.17.camel@nirvana> Il giorno mer, 10/09/2008 alle 15.45 -0700, Dmitri Trembovetski ha scritto: > --- a/src/solaris/native/sun/awt/fontpath.c Thu Aug 07 09:42:31 2008 -0700 > +++ b/src/solaris/native/sun/awt/fontpath.c Wed Sep 10 23:52:15 2008 +0200 > @@ -156,7 +156,7 @@ > > isLocal = JNU_CallStaticMethodByName(env, NULL, > "sun/awt/X11GraphicsEnvironment", > - "isDisplayLocal", > + "_isDisplayLocal", > "()Z").z; Hi Dmitri! Calling "isDisplayLocal" fires up a infinite loop. Here we call _isDisplayLocal, which is declared as: private static boolean _isDisplayLocal And we don't touch it in the patch. We are not super happy with this, but I don't see much alternatives. This code is X11 specific anyway. All this Font code is really sensible to this kind of infinite loops... Cheers, Mario -- ?Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-53 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ From roman at kennke.org Wed Sep 10 16:45:08 2008 From: roman at kennke.org (Roman Kennke) Date: Thu, 11 Sep 2008 01:45:08 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <48C84DF0.1090506@Sun.COM> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> <48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight> <1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM> Message-ID: <1221090308.6500.3.camel@moonlight> Hi Dmitri, > > I need to repost my original patch for two reasons: 1. it doesn't apply > > cleanly (only with some fuzz), 2. it also has this init-loop problem. > > Find attached the correct version. I'd be happy to see it committed > > ASAP. > > I have a question about the fix: > --- a/src/solaris/native/sun/awt/fontpath.c Thu Aug 07 09:42:31 2008 -0700 > +++ b/src/solaris/native/sun/awt/fontpath.c Wed Sep 10 23:52:15 2008 +0200 > @@ -156,7 +156,7 @@ > > isLocal = JNU_CallStaticMethodByName(env, NULL, > "sun/awt/X11GraphicsEnvironment", > - "isDisplayLocal", > + "_isDisplayLocal", > "()Z").z; > > Didn't you change isDisplayLocal to be non-static > in X11GraphicsEnvironment? If so how does this actually > work since you still call CallStaticMethodByName? The _isDisplayLocal() is a static method in X11GraphicsEnvironment, which is called by isDisplayLocal() after entering the AWT monitor. The above code is already executed inside the AWT lock, so this is not a problem. And it is only called from the X11 backend anyway. Calling isDisplayLocal() results in a loop though, because it tries to load the X11GraphicsEnvironment class, which in turn causes the class initializer of SGE to be executed, which calls back into the code above, ad infinitum. This is why we call the static _isDisplayLocal() instead. The real solution would be to rework all the SGE and FontManager code, which we did, but send in a separate patch. :-) (You can also take a peek at this code in our repository (http://hg.openjdk.java.net/caciocavallo/jdk7/) ). Thanks, Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080911/ec816682/attachment.bin From Dmitri.Trembovetski at Sun.COM Wed Sep 10 16:54:02 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 10 Sep 2008 16:54:02 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <1221090308.6500.3.camel@moonlight> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> <48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight> <1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM> <1221090308.6500.3.camel@moonlight> Message-ID: <48C85E1A.3030801@Sun.COM> Yep, I see. I didn't look at the file itself, only at the patch, and got confused. Thanks, Dmitri Roman Kennke wrote: > Hi Dmitri, > >>> I need to repost my original patch for two reasons: 1. it doesn't apply >>> cleanly (only with some fuzz), 2. it also has this init-loop problem. >>> Find attached the correct version. I'd be happy to see it committed >>> ASAP. >> I have a question about the fix: >> --- a/src/solaris/native/sun/awt/fontpath.c Thu Aug 07 09:42:31 2008 -0700 >> +++ b/src/solaris/native/sun/awt/fontpath.c Wed Sep 10 23:52:15 2008 +0200 >> @@ -156,7 +156,7 @@ >> >> isLocal = JNU_CallStaticMethodByName(env, NULL, >> "sun/awt/X11GraphicsEnvironment", >> - "isDisplayLocal", >> + "_isDisplayLocal", >> "()Z").z; >> >> Didn't you change isDisplayLocal to be non-static >> in X11GraphicsEnvironment? If so how does this actually >> work since you still call CallStaticMethodByName? > > The _isDisplayLocal() is a static method in X11GraphicsEnvironment, > which is called by isDisplayLocal() after entering the AWT monitor. The > above code is already executed inside the AWT lock, so this is not a > problem. And it is only called from the X11 backend anyway. Calling > isDisplayLocal() results in a loop though, because it tries to load the > X11GraphicsEnvironment class, which in turn causes the class initializer > of SGE to be executed, which calls back into the code above, ad > infinitum. This is why we call the static _isDisplayLocal() instead. The > real solution would be to rework all the SGE and FontManager code, which > we did, but send in a separate patch. :-) (You can also take a peek at > this code in our repository > (http://hg.openjdk.java.net/caciocavallo/jdk7/) ). > > Thanks, Roman > > From roman at kennke.org Fri Sep 12 00:42:11 2008 From: roman at kennke.org (Roman Kennke) Date: Fri, 12 Sep 2008 09:42:11 +0200 Subject: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay() In-Reply-To: <48C85E1A.3030801@Sun.COM> References: <1220640905.6422.43.camel@moonlight> <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com> <1220691841.6571.22.camel@moonlight> <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com> <1220900673.7112.25.camel@moonlight> <1220901074.7112.27.camel@moonlight> <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com> <48C6BD74.1070705@Sun.COM> <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com> <48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight> <1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM> <1221090308.6500.3.camel@moonlight> <48C85E1A.3030801@Sun.COM> Message-ID: <1221205331.6511.0.camel@moonlight> Hi, > Yep, I see. I didn't look at the file itself, only at the > patch, and got confused. Ok, what's next? Will the patch be included? /Roman > > Thanks, > Dmitri > > > Roman Kennke wrote: > > Hi Dmitri, > > > >>> I need to repost my original patch for two reasons: 1. it doesn't apply > >>> cleanly (only with some fuzz), 2. it also has this init-loop problem. > >>> Find attached the correct version. I'd be happy to see it committed > >>> ASAP. > >> I have a question about the fix: > >> --- a/src/solaris/native/sun/awt/fontpath.c Thu Aug 07 09:42:31 2008 -0700 > >> +++ b/src/solaris/native/sun/awt/fontpath.c Wed Sep 10 23:52:15 2008 +0200 > >> @@ -156,7 +156,7 @@ > >> > >> isLocal = JNU_CallStaticMethodByName(env, NULL, > >> "sun/awt/X11GraphicsEnvironment", > >> - "isDisplayLocal", > >> + "_isDisplayLocal", > >> "()Z").z; > >> > >> Didn't you change isDisplayLocal to be non-static > >> in X11GraphicsEnvironment? If so how does this actually > >> work since you still call CallStaticMethodByName? > > > > The _isDisplayLocal() is a static method in X11GraphicsEnvironment, > > which is called by isDisplayLocal() after entering the AWT monitor. The > > above code is already executed inside the AWT lock, so this is not a > > problem. And it is only called from the X11 backend anyway. Calling > > isDisplayLocal() results in a loop though, because it tries to load the > > X11GraphicsEnvironment class, which in turn causes the class initializer > > of SGE to be executed, which calls back into the code above, ad > > infinitum. This is why we call the static _isDisplayLocal() instead. The > > real solution would be to rework all the SGE and FontManager code, which > > we did, but send in a separate patch. :-) (You can also take a peek at > > this code in our repository > > (http://hg.openjdk.java.net/caciocavallo/jdk7/) ). > > > > Thanks, Roman > > > > -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080912/ee2c4cda/attachment.bin From dmitri.trembovetski at sun.com Fri Sep 12 15:05:42 2008 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Fri, 12 Sep 2008 22:05:42 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal Message-ID: <20080912220554.0E41CDB92@hg.openjdk.java.net> Changeset: b8f91ea2fb33 Author: tdv Date: 2008-09-12 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b8f91ea2fb33 6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal Reviewed-by: prr, tdv Contributed-by: rkennke at kennke.org ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java From roman.kennke at aicas.com Wed Sep 17 05:40:52 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 17 Sep 2008 14:40:52 +0200 Subject: [OpenJDK 2D-Dev] Thoughts about font implementation In-Reply-To: <1218540561.10101.32.camel@moonlight> References: <1218540561.10101.32.camel@moonlight> Message-ID: <1221655252.32395.2.camel@moonlight> So, no more opinions on this proposed change? /Roman Am Dienstag, den 12.08.2008, 13:29 +0200 schrieb Roman Kennke: > Hi there, > > I have a small problem with current implementation of fonts in OpenJDK. > It is required that fonts are present as files, and that all fonts are > loaded via a FileChannel, not InputStream, because FreeType doesn't > support loading from a sequential-only stream. From my perspective as > embedded VM developer this is not very practical. Ideally I'd like to be > able to embed fonts in the classpath (with the Jamaica VM you can create > a complete image of an application+VM+resources and don't need anything > else on the target machine, sometimes not even a filesystem). I can't do > that using the current approach in OpenJDK. I have some ideas how to > change it, and I think there are also some advantages for the more > general OpenJDK community. Here's my plan which I'd like to discuss: > > - Change TrueTypeFont and all related classes (these are a lot) to read > from a (direct) ByteBuffer, instead of a file channel. FreeType can read > fonts directly from a memory buffer, this would make a lot of code > easier (i.e. freetypeScaler.c wouldn't need these callbacks). > - At a slightly higher level, don't pass FileChannels to TrueTypeFont to > read from, but instead map the file, and pass the resulting buffer. I'm > not sure about all the OS level details, but I think it is possible that > the OS does some interesting optimizations here. For example, if the OS > already has the font file open (for the desktop), this can be reused, > and should be faster than reading into a new buffer. > - File.createFont(InputStream) could be changed to read from the stream > into a memory buffer, instead of a temporary file. > > For me personally, this means that I could access the app+VM+resources > image directly using a (direct) ByteBuffer and pass that to read fonts > from the classpath, thus solving my problem. > > What do you think about this rough outline? Maybe you have other ideas > how to solve my problem? Would such a change have a chance to be > accepted into OpenJDK mainline? (I'd try hard to avoid having to > maintain a fork of the code.) > > Kind regards, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Phil.Race at Sun.COM Thu Sep 18 14:26:16 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 18 Sep 2008 14:26:16 -0700 Subject: [OpenJDK 2D-Dev] Thoughts about font implementation In-Reply-To: <1221655252.32395.2.camel@moonlight> References: <1218540561.10101.32.camel@moonlight> <1221655252.32395.2.camel@moonlight> Message-ID: <48D2C778.2070608@sun.com> I haven't really had time to review this in the depth it merits My high-level thoughts - Yes, its definitely makes the code simpler - I think its probably peformance neutral - at least as can be detected in the SE JDK. - It probably does increase perceived footprint although results will probably vary by platform and we'd need to see if people will accept that. I did what I hope is a reasonably fair comparison of the two approaches, reading all font files on my XP system takes mem usage up to 160Mb with the new approach, vs 37Mb with the existing approach. That's not a test doing rendering, just treating them as files and reading them all in and discarding the actual file data, although the mmapp'ed direct bytes are kept around as they would be in the actual JDK implementation. - There are some cases that need additional work here * T2K also, like any rasteriser will need to randomly access the file, so has similar code. * The new init() methods don't seem to use all their args. In particular the T1 font doesn't do anything with the buffer it just read http://kennke.org/~roman/fontwork/webrev/src/share/classes/sun/font/Type1Font.java.sdiff.html * Want to make sure that this works well for the Font.createFont() cases. The the only way the BB resources can be freed is via GC. So we have no timely way to release these resources, And on windows, you can't "delete" a file that's mmapped, so you need to be able to know when GC has allowed NIO to free its map with windows before you can delete the file, otherwise we'd leave temp files on disk, which is something we've tried had to clean up. - Not thought about this much, but even if the above doesn't work out for all the SE cases, there's probably no fundamental obstacle to providing a DBB path which can be optionally used. -Phil. Roman Kennke wrote: > So, no more opinions on this proposed change? > > /Roman > > Am Dienstag, den 12.08.2008, 13:29 +0200 schrieb Roman Kennke: >> Hi there, >> >> I have a small problem with current implementation of fonts in OpenJDK. >> It is required that fonts are present as files, and that all fonts are >> loaded via a FileChannel, not InputStream, because FreeType doesn't >> support loading from a sequential-only stream. From my perspective as >> embedded VM developer this is not very practical. Ideally I'd like to be >> able to embed fonts in the classpath (with the Jamaica VM you can create >> a complete image of an application+VM+resources and don't need anything >> else on the target machine, sometimes not even a filesystem). I can't do >> that using the current approach in OpenJDK. I have some ideas how to >> change it, and I think there are also some advantages for the more >> general OpenJDK community. Here's my plan which I'd like to discuss: >> >> - Change TrueTypeFont and all related classes (these are a lot) to read >> from a (direct) ByteBuffer, instead of a file channel. FreeType can read >> fonts directly from a memory buffer, this would make a lot of code >> easier (i.e. freetypeScaler.c wouldn't need these callbacks). >> - At a slightly higher level, don't pass FileChannels to TrueTypeFont to >> read from, but instead map the file, and pass the resulting buffer. I'm >> not sure about all the OS level details, but I think it is possible that >> the OS does some interesting optimizations here. For example, if the OS >> already has the font file open (for the desktop), this can be reused, >> and should be faster than reading into a new buffer. >> - File.createFont(InputStream) could be changed to read from the stream >> into a memory buffer, instead of a temporary file. >> >> For me personally, this means that I could access the app+VM+resources >> image directly using a (direct) ByteBuffer and pass that to read fonts >> from the classpath, thus solving my problem. >> >> What do you think about this rough outline? Maybe you have other ideas >> how to solve my problem? Would such a change have a chance to be >> accepted into OpenJDK mainline? (I'd try hard to avoid having to >> maintain a fork of the code.) >> >> Kind regards, Roman From roman.kennke at aicas.com Fri Sep 19 01:04:15 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 19 Sep 2008 10:04:15 +0200 Subject: [OpenJDK 2D-Dev] Thoughts about font implementation In-Reply-To: <48D2C778.2070608@sun.com> References: <1218540561.10101.32.camel@moonlight> <1221655252.32395.2.camel@moonlight> <48D2C778.2070608@sun.com> Message-ID: <1221811455.7545.11.camel@moonlight> Hi Phil, > - I think its probably peformance neutral - at least as can be > detected in the SE JDK. Yeah, that's what I found too. If anything, it becomes very little faster, but that can also be normal jitter during testing. > - It probably does increase perceived footprint although > results will probably vary by platform and > we'd need to see if people will accept that. I did what > I hope is a reasonably fair comparison of the two approaches, > reading all font files on my XP system takes mem usage up to 160Mb > with the new approach, vs 37Mb with the existing approach. That is virtual memory or actual resident memory? Sure - virtual memory mapped into the process increases significantly, as all the font files appear to be loaded completely into the process. Actual used resident memory should not increase (at least, did not for my tests under linux). But I see that the problem is that people use flawed memory usage analysis tools and will probably scream if the VM uses twice as much memory than before. > - There are some cases that need additional work here > * T2K also, like any rasteriser will need to randomly access the file, > so has similar code. Unfortunately I have no control over that code. > * The new init() methods don't seem to use all their args. > In particular the T1 font doesn't do anything with the buffer it just read > http://kennke.org/~roman/fontwork/webrev/src/share/classes/sun/font/Type1Font.java.sdiff.html Oops right. I didn't finish up the Type1 stuff it seems. I can do that if we come to the conclusion that we actually want this code in OpenJDK. > * Want to make sure that this works well for the Font.createFont() cases. > The the only way the BB resources can be freed is via GC. So we have no timely > way to release these resources, > And on windows, you can't "delete" a file that's mmapped, so you need > to be able to know when GC has allowed NIO to free its map with windows > before you can delete the file, otherwise we'd leave temp files on disk, > which is something we've tried had to clean up. Hmm, Font.createFont(InputStream) is a strange beast. I don't like the idea to copy the stream into a temporary file to begin with. But you are right, we need to take care of this. For the situation on Windows we could probably do something with PhantomReference and ReferenceQueue. An alternative would be to not copy the stream but instead read it into a ByteBuffer, but this means we'd have to keep all the font data of the stream in memory. I'd prefer the latter solution because on the systems I work on I can't guarantee that I have tmp space on the disk at all, but I suppose for JDK SE it probably makes more sense to copy into temporary files. > - Not thought about this much, but even if the above doesn't work out for > all the SE cases, there's probably no fundamental obstacle to providing > a DBB path which can be optionally used. That would be very cool. I'd have to think about how we could have both in parallel. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Igor.Nekrestyanov at Sun.COM Fri Sep 19 01:12:18 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Fri, 19 Sep 2008 12:12:18 +0400 Subject: [OpenJDK 2D-Dev] Thoughts about font implementation In-Reply-To: <1221811455.7545.11.camel@moonlight> References: <1218540561.10101.32.camel@moonlight> <1221655252.32395.2.camel@moonlight> <48D2C778.2070608@sun.com> <1221811455.7545.11.camel@moonlight> Message-ID: <48D35EE2.5010107@sun.com> >> - It probably does increase perceived footprint although >> results will probably vary by platform and >> we'd need to see if people will accept that. I did what >> I hope is a reasonably fair comparison of the two approaches, >> reading all font files on my XP system takes mem usage up to 160Mb >> with the new approach, vs 37Mb with the existing approach. >> > > That is virtual memory or actual resident memory? Sure - virtual memory > mapped into the process increases significantly, as all the font files > appear to be loaded completely into the process. Actual used resident > memory should not increase (at least, did not for my tests under linux). > But I see that the problem is that people use flawed memory usage > analysis tools and will probably scream if the VM uses twice as much > memory than before. > Yep, this is virtual memory. Unfortunately this is what people look at using windows task manager :( >> - There are some cases that need additional work here >> * T2K also, like any rasteriser will need to randomly access the file, >> so has similar code. >> > > Unfortunately I have no control over that code. > I can add necessary support on t2k side if it will be needed. -igor From roman.kennke at aicas.com Mon Sep 22 12:46:11 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Mon, 22 Sep 2008 21:46:11 +0200 Subject: [OpenJDK 2D-Dev] Thoughts about font implementation In-Reply-To: <48D2C778.2070608@sun.com> References: <1218540561.10101.32.camel@moonlight> <1221655252.32395.2.camel@moonlight> <48D2C778.2070608@sun.com> Message-ID: <1222112771.10091.7.camel@moonlight> Ok, here we have an improved version of the idea, that let's the standard code path (using FileChannel etc) in and the default, and adds a code path that uses direct byte buffers. I'm only adding this to TrueTypeFont for now, should be good as a first prototype, and Type1 should be easy to add, as this uses direct buffers anyway. I tested the alternative code path by putting some additional code in the (old) constructor that makes a direct buffer out of the font file and use that instead of using the channel. Works fine for me. What else is needed to make this patch go into OpenJDK tree? http://kennke.org/~roman/truetypefrombuffer/webrev/ Cheers, Roman Am Donnerstag, den 18.09.2008, 14:26 -0700 schrieb Phil Race: > I haven't really had time to review this in the depth it merits > > My high-level thoughts > > - Yes, its definitely makes the code simpler > > - I think its probably peformance neutral - at least as can be > detected in the SE JDK. > > - It probably does increase perceived footprint although > results will probably vary by platform and > we'd need to see if people will accept that. I did what > I hope is a reasonably fair comparison of the two approaches, > reading all font files on my XP system takes mem usage up to 160Mb > with the new approach, vs 37Mb with the existing approach. > That's not a test doing rendering, just treating them as files and > reading them all in and discarding the actual file data, > although the mmapp'ed direct bytes are kept around as they would be > in the actual JDK implementation. > > - There are some cases that need additional work here > * T2K also, like any rasteriser will need to randomly access the > file, > so has similar code. > * The new init() methods don't seem to use all their args. > In particular the T1 font doesn't do anything with the buffer it > just read > http://kennke.org/~roman/fontwork/webrev/src/share/classes/sun/font/Type1Font.java.sdiff.html > * Want to make sure that this works well for the Font.createFont() > cases. > The the only way the BB resources can be freed is via GC. So we > have no timely > way to release these resources, > And on windows, you can't "delete" a file that's mmapped, so you > need > to be able to know when GC has allowed NIO to free its map with > windows > before you can delete the file, otherwise we'd leave temp files > on disk, > which is something we've tried had to clean up. > > - Not thought about this much, but even if the above doesn't work out > for > all the SE cases, there's probably no fundamental obstacle to > providing > a DBB path which can be optionally used. > > -Phil. > > Roman Kennke wrote: > > So, no more opinions on this proposed change? > > > > /Roman > > > > Am Dienstag, den 12.08.2008, 13:29 +0200 schrieb Roman Kennke: > >> Hi there, > >> > >> I have a small problem with current implementation of fonts in > OpenJDK. > >> It is required that fonts are present as files, and that all fonts > are > >> loaded via a FileChannel, not InputStream, because FreeType doesn't > >> support loading from a sequential-only stream. From my perspective > as > >> embedded VM developer this is not very practical. Ideally I'd like > to be > >> able to embed fonts in the classpath (with the Jamaica VM you can > create > >> a complete image of an application+VM+resources and don't need > anything > >> else on the target machine, sometimes not even a filesystem). I > can't do > >> that using the current approach in OpenJDK. I have some ideas how > to > >> change it, and I think there are also some advantages for the more > >> general OpenJDK community. Here's my plan which I'd like to > discuss: > >> > >> - Change TrueTypeFont and all related classes (these are a lot) to > read > >> from a (direct) ByteBuffer, instead of a file channel. FreeType can > read > >> fonts directly from a memory buffer, this would make a lot of code > >> easier (i.e. freetypeScaler.c wouldn't need these callbacks). > >> - At a slightly higher level, don't pass FileChannels to > TrueTypeFont to > >> read from, but instead map the file, and pass the resulting buffer. > I'm > >> not sure about all the OS level details, but I think it is possible > that > >> the OS does some interesting optimizations here. For example, if > the OS > >> already has the font file open (for the desktop), this can be > reused, > >> and should be faster than reading into a new buffer. > >> - File.createFont(InputStream) could be changed to read from the > stream > >> into a memory buffer, instead of a temporary file. > >> > >> For me personally, this means that I could access the app+VM > +resources > >> image directly using a (direct) ByteBuffer and pass that to read > fonts > >> from the classpath, thus solving my problem. > >> > >> What do you think about this rough outline? Maybe you have other > ideas > >> how to solve my problem? Would such a change have a chance to be > >> accepted into OpenJDK mainline? (I'd try hard to avoid having to > >> maintain a fork of the code.) > >> > >> Kind regards, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From phil.race at sun.com Wed Sep 24 12:02:35 2008 From: phil.race at sun.com (phil.race at sun.com) Date: Wed, 24 Sep 2008 19:02:35 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6751621: TextLayout.getBounds() doesn't account for strike through Message-ID: <20080924190254.836DDD1C1@hg.openjdk.java.net> Changeset: 41ff3f84cd96 Author: prr Date: 2008-09-24 11:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/41ff3f84cd96 6751621: TextLayout.getBounds() doesn't account for strike through Reviewed-by: igor, dougfelt ! src/share/classes/sun/font/Decoration.java ! src/share/classes/sun/font/Underline.java + test/java/awt/font/TextLayout/DecorationBoundsTest.java