From bccheng at google.com  Wed Feb  6 18:45:54 2008
From: bccheng at google.com (Ben Cheng)
Date: Wed, 6 Feb 2008 10:45:54 -0800
Subject: [OpenJDK 2D-Dev] JVM crash in libc pre JDK7
Message-ID: <bcf6f6d40802061045q29b9a3fp114eee96b84a549f@mail.gmail.com>

Not sure this is the right place to ask this question, but I am going to
give it a try.

We are seeing some JVM crashes in libc malloc()/free() invoked from
libdcpr.so with Java 6. After browsing the bug database there are a few
similar ones as described in 6510993 and 6645511. I used the SwingSet2
example from 6510993 as the benchmark and I usually can reproduce the crash
within a couple hours, but for some reason the crash is simply not
reproducible with openjdk7.

With server VM build 1.6.0-b105 the stack trace in the core file looks like
the following:


#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4bdce9a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x4bdd02b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x0643b36b in os::abort ()
   from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
#4  0x0651c431 in VMError::report_and_die ()
   from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
#5  0x0643f7a0 in JVM_handle_linux_signal ()
   from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
#6  0x0643d058 in signalHandler ()
   from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
#7  <signal handler called>
#8  0x4be0863b in malloc_consolidate () from /lib/tls/i686/cmov/libc.so.6
#9  0x4be09653 in _int_malloc () from /lib/tls/i686/cmov/libc.so.6
#10 0x4be0b411 in malloc () from /lib/tls/i686/cmov/libc.so.6
#11 0xb263a1c5 in doeMem_malloc ()
   from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
#12 0xb2643c61 in setOutputArea ()
   from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
#13 0xb263cdf4 in Java_sun_dc_pr_PathFiller_setOutputArea ()
   from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so

I checked the openjdk7 code structure and found that heavy redesign seems
happening under sun/dc, as everything below pr is simply gone. That makes me
believe that whatever the problem is on Java 6 it is likely to be related to
the implementation under pr.

Here comes my main question: for people who rewrite sun/dc for openjdk7, do
you happen to know any patch to workaround the crashes in Java 6? We are
happy to try any patch to eliminate the annoying JVM crashes.

Thanks,
-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080206/2d18b511/attachment.html>

From Phil.Race at Sun.COM  Wed Feb  6 19:26:43 2008
From: Phil.Race at Sun.COM (Phil Race)
Date: Wed, 06 Feb 2008 11:26:43 -0800
Subject: [OpenJDK 2D-Dev] JVM crash in libc pre JDK7
In-Reply-To: <bcf6f6d40802061045q29b9a3fp114eee96b84a549f@mail.gmail.com>
References: <bcf6f6d40802061045q29b9a3fp114eee96b84a549f@mail.gmail.com>
Message-ID: <47AA09F3.3080708@sun.com>

libdcpr.so is third party code that couldn't be included in openjdk,
so there is a different, but lower-performing, replacement. Granted
it doesn't crash for you, but it could have its own problems as
its relatively untested.

This only applies to openjdk. If you download the jdk7 commercial
binary builds (pre-release of course), from http://download.java.net/jdk7/binaries/
then you'll likely find it has the same problems as jdk6.
So I don't know of any patch.

Yes, there have been similar reports, with the common thread
that they are mighty hard to reproduce.

Precisely how did you use SwingSet over those two hours to produce the crash?

What O/S and version are you using?

-phil.


Ben Cheng wrote:
> Not sure this is the right place to ask this question, but I am going to 
> give it a try.
> 
> We are seeing some JVM crashes in libc malloc()/free() invoked from 
> libdcpr.so with Java 6. After browsing the bug database there are a few 
> similar ones as described in 6510993 and 6645511. I used the SwingSet2 
> example from 6510993 as the benchmark and I usually can reproduce the 
> crash within a couple hours, but for some reason the crash is simply not 
> reproducible with openjdk7.
> 
> With server VM build 1.6.0-b105 the stack trace in the core file looks 
> like the following:
> 
> 
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0x4bdce9a1 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2  0x4bdd02b9 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3  0x0643b36b in os::abort ()
>    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> #4  0x0651c431 in VMError::report_and_die ()
>    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> #5  0x0643f7a0 in JVM_handle_linux_signal ()
>    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> #6  0x0643d058 in signalHandler ()
>    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> #7  <signal handler called>
> #8  0x4be0863b in malloc_consolidate () from /lib/tls/i686/cmov/libc.so.6
> #9  0x4be09653 in _int_malloc () from /lib/tls/i686/cmov/libc.so.6
> #10 0x4be0b411 in malloc () from /lib/tls/i686/cmov/libc.so.6
> #11 0xb263a1c5 in doeMem_malloc ()
>    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
> #12 0xb2643c61 in setOutputArea ()
>    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
> #13 0xb263cdf4 in Java_sun_dc_pr_PathFiller_setOutputArea ()
>    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
> 
> I checked the openjdk7 code structure and found that heavy redesign 
> seems happening under sun/dc, as everything below pr is simply gone. 
> That makes me believe that whatever the problem is on Java 6 it is 
> likely to be related to the implementation under pr.
> 
> Here comes my main question: for people who rewrite sun/dc for openjdk7, 
> do you happen to know any patch to workaround the crashes in Java 6? We 
> are happy to try any patch to eliminate the annoying JVM crashes.
> 
> Thanks,
> -Ben
> 


From bccheng at google.com  Wed Feb  6 20:09:08 2008
From: bccheng at google.com (Ben Cheng)
Date: Wed, 6 Feb 2008 12:09:08 -0800
Subject: [OpenJDK 2D-Dev] JVM crash in libc pre JDK7
In-Reply-To: <47AA09F3.3080708@sun.com>
References: <bcf6f6d40802061045q29b9a3fp114eee96b84a549f@mail.gmail.com>
	<47AA09F3.3080708@sun.com>
Message-ID: <bcf6f6d40802061209k7d19ce9dm70c50c32151a7eec@mail.gmail.com>

Hi Phil,

Thanks for the extra information.

In the original bug report they claim that the crash can be reproduced with
the "ColorChooser Demo", but it is not the default component when the app
launches. Furthermore, through some manual experiments I found if the VM is
going to crash it usually takes less than 30 seconds.

So I hacked the code to make ColorChooser Demo the default mode when the app
is launched, and add a timer thread which will terminate the app after 30
seconds. Than I just use the following bash loop to run it infinitely:

while true; do java -jar SwingSet2.jar; done

With Java 6 I usually can get a crash within a couple hours. I tried
openjdk7 over the weekend but there was no single crash recorded.

If you want to access my modified SwingSet2.jar I can send it to you in a
private mail so that I won't bloat everyone's inbox.

Thanks,
-Ben

On Feb 6, 2008 11:26 AM, Phil Race <Phil.Race at sun.com> wrote:

> libdcpr.so is third party code that couldn't be included in openjdk,
> so there is a different, but lower-performing, replacement. Granted
> it doesn't crash for you, but it could have its own problems as
> its relatively untested.
>
> This only applies to openjdk. If you download the jdk7 commercial
> binary builds (pre-release of course), from
> http://download.java.net/jdk7/binaries/
> then you'll likely find it has the same problems as jdk6.
> So I don't know of any patch.
>
> Yes, there have been similar reports, with the common thread
> that they are mighty hard to reproduce.
>
> Precisely how did you use SwingSet over those two hours to produce the
> crash?
>
> What O/S and version are you using?
>
> -phil.
>
>
> Ben Cheng wrote:
> > Not sure this is the right place to ask this question, but I am going to
> > give it a try.
> >
> > We are seeing some JVM crashes in libc malloc()/free() invoked from
> > libdcpr.so with Java 6. After browsing the bug database there are a few
> > similar ones as described in 6510993 and 6645511. I used the SwingSet2
> > example from 6510993 as the benchmark and I usually can reproduce the
> > crash within a couple hours, but for some reason the crash is simply not
> > reproducible with openjdk7.
> >
> > With server VM build 1.6.0-b105 the stack trace in the core file looks
> > like the following:
> >
> >
> > #0  0xffffe410 in __kernel_vsyscall ()
> > #1  0x4bdce9a1 in raise () from /lib/tls/i686/cmov/libc.so.6
> > #2  0x4bdd02b9 in abort () from /lib/tls/i686/cmov/libc.so.6
> > #3  0x0643b36b in os::abort ()
> >    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> > #4  0x0651c431 in VMError::report_and_die ()
> >    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> > #5  0x0643f7a0 in JVM_handle_linux_signal ()
> >    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> > #6  0x0643d058 in signalHandler ()
> >    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/server/libjvm.so
> > #7  <signal handler called>
> > #8  0x4be0863b in malloc_consolidate () from
> /lib/tls/i686/cmov/libc.so.6
> > #9  0x4be09653 in _int_malloc () from /lib/tls/i686/cmov/libc.so.6
> > #10 0x4be0b411 in malloc () from /lib/tls/i686/cmov/libc.so.6
> > #11 0xb263a1c5 in doeMem_malloc ()
> >    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
> > #12 0xb2643c61 in setOutputArea ()
> >    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
> > #13 0xb263cdf4 in Java_sun_dc_pr_PathFiller_setOutputArea ()
> >    from /auto/buildtools/java/jdk1.6.0/jre/lib/i386/libdcpr.so
> >
> > I checked the openjdk7 code structure and found that heavy redesign
> > seems happening under sun/dc, as everything below pr is simply gone.
> > That makes me believe that whatever the problem is on Java 6 it is
> > likely to be related to the implementation under pr.
> >
> > Here comes my main question: for people who rewrite sun/dc for openjdk7,
> > do you happen to know any patch to workaround the crashes in Java 6? We
> > are happy to try any patch to eliminate the annoying JVM crashes.
> >
> > Thanks,
> > -Ben
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080206/a2f82e5f/attachment.html>

From Phil.Race at Sun.COM  Thu Feb 14 01:51:49 2008
From: Phil.Race at Sun.COM (Phil Race)
Date: Wed, 13 Feb 2008 17:51:49 -0800
Subject: [OpenJDK 2D-Dev] imaging and color classes binary plugs no longer
	needed (soon)
Message-ID: <47B39EB5.3000506@sun.com>

One of the most glaring holes to date in the openjdk sources are a 
couple of dozen 2D classes
visible at the API level in the packages java.awt.color, java.awt.image, 
and java.awt.image.renderable.

These have been held back from the sources (but included in the binary 
plugs) until we (Sun)
established we could release these under GPL v2  +CP (ie same as most of 
the rest as OpenJDK)

Just today we got the OK to do that, so at the next opportunity these 
classes will appear
in the open jdk sources.

Due to the hold-up around the mercurial repositories its pretty much a 
certainty they'll
appear first in the OpenJDK 6 drop, probably as early as sometime next week.

-phil.




From robilad at kaffe.org  Thu Feb 14 14:39:42 2008
From: robilad at kaffe.org (Dalibor Topic)
Date: Thu, 14 Feb 2008 15:39:42 +0100
Subject: [OpenJDK 2D-Dev] imaging and color classes binary plugs no
	longer needed (soon)
In-Reply-To: <47B39EB5.3000506@sun.com>
References: <47B39EB5.3000506@sun.com>
Message-ID: <47B452AE.8030304@kaffe.org>

Phil Race wrote:
> One of the most glaring holes to date in the openjdk sources are a 
> couple of dozen 2D classes
> visible at the API level in the packages java.awt.color, 
> java.awt.image, and java.awt.image.renderable.
>
> These have been held back from the sources (but included in the binary 
> plugs) until we (Sun)
> established we could release these under GPL v2  +CP (ie same as most 
> of the rest as OpenJDK)
>
> Just today we got the OK to do that, so at the next opportunity these 
> classes will appear
> in the open jdk sources.
>
> Due to the hold-up around the mercurial repositories its pretty much a 
> certainty they'll
> appear first in the OpenJDK 6 drop, probably as early as sometime next 
> week.
That's very good news.

thank you,
dalibor topic


From roman.kennke at aicas.com  Thu Feb 14 19:48:42 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Thu, 14 Feb 2008 20:48:42 +0100
Subject: [OpenJDK 2D-Dev] imaging and color classes binary plugs no
	longer needed (soon)
In-Reply-To: <47B39EB5.3000506@sun.com>
References: <47B39EB5.3000506@sun.com>
Message-ID: <1203018522.5925.27.camel@mercury>

Hi Phil,

> One of the most glaring holes to date in the openjdk sources are a 
> couple of dozen 2D classes
> visible at the API level in the packages java.awt.color, java.awt.image, 
> and java.awt.image.renderable.
> 
> These have been held back from the sources (but included in the binary 
> plugs) until we (Sun)
> established we could release these under GPL v2  +CP (ie same as most of 
> the rest as OpenJDK)
> 
> Just today we got the OK to do that, so at the next opportunity these 
> classes will appear
> in the open jdk sources.

This is supercool! Thanks alot!

Cheers, Roman

PS: Unfortunately, they don't appear to be in the freshly released JDK6
sources. But waiting another few days only makes the release sweeter ;-)
-- 
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-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Joe.Darcy at Sun.COM  Thu Feb 14 19:59:34 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 14 Feb 2008 11:59:34 -0800
Subject: [OpenJDK 2D-Dev] imaging and color classes binary plugs no
	longer needed (soon)
In-Reply-To: <1203018522.5925.27.camel@mercury>
References: <47B39EB5.3000506@sun.com> <1203018522.5925.27.camel@mercury>
Message-ID: <47B49DA6.4010106@sun.com>

Roman Kennke wrote:
> Hi Phil,
>
>   
>> One of the most glaring holes to date in the openjdk sources are a 
>> couple of dozen 2D classes
>> visible at the API level in the packages java.awt.color, java.awt.image, 
>> and java.awt.image.renderable.
>>
>> These have been held back from the sources (but included in the binary 
>> plugs) until we (Sun)
>> established we could release these under GPL v2  +CP (ie same as most of 
>> the rest as OpenJDK)
>>
>> Just today we got the OK to do that, so at the next opportunity these 
>> classes will appear
>> in the open jdk sources.
>>     
>
> This is supercool! Thanks alot!
>
> Cheers, Roman
>
> PS: Unfortunately, they don't appear to be in the freshly released JDK6
> sources. But waiting another few days only makes the release sweeter ;-)
>   

Yes, those changes for the OpenJDK 6 sources are in the works:
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000004.html

-Joe


From lists at munckfish.net  Fri Feb 15 22:22:22 2008
From: lists at munckfish.net (Dan Munckton)
Date: Fri, 15 Feb 2008 22:22:22 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
	Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <478FA100.7070401@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan>  <478FA100.7070401@Sun.COM>
Message-ID: <1203114142.12409.2.camel@dylan>

Hi Dmitri

>    Regarding testing configurations: I have requested
>    a sparc system with Nevada (so that it has the new X server),
>    and also an x86/64 machine for linux/solaris. Once
>    we have those set up we can proceed with the integration.

How's it going? Have these beasts arrived yet?

Cheers

Dan



From Dmitri.Trembovetski at Sun.COM  Fri Feb 15 23:34:51 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 15 Feb 2008 15:34:51 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
 Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1203114142.12409.2.camel@dylan>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
	<1203114142.12409.2.camel@dylan>
Message-ID: <47B6219B.50005@Sun.COM>


   Hi Dan,

Dan Munckton wrote:
> Hi Dmitri
> 
>>    Regarding testing configurations: I have requested
>>    a sparc system with Nevada (so that it has the new X server),
>>    and also an x86/64 machine for linux/solaris. Once
>>    we have those set up we can proceed with the integration.
> 
> How's it going? Have these beasts arrived yet?

   Unfortunately not =(

   I think we'll just have to proceed w/o them.
   The good news is that we can probably integrate this fix into
   the newly created 6open workspace so that the fix gets into
   the major linux distros quickly.

   Thanks,
     Dmitri


From roman.kennke at aicas.com  Tue Feb 26 16:53:56 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 26 Feb 2008 17:53:56 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] SurfaceManagerFactory
Message-ID: <1204044836.7087.42.camel@mercury>

Hello,

I'm implementing a Java2D backend based on Escher, which is already
working quite well (for a couple-of-hours-prototype):

http://kennke.org/blog/2008/02/25/escher-on-openjdk-graphics/

One issue I came over is the SurfaceManagerFactory. There seems to be
such a factory class both in the solaris and windows source trees, but
no way to provide an own implementation. Therefore I propose the
attached change. This basically turns the SurfaceManagerFactory into an
abstract class, now in the shared tree, with appropriate subclasses in
the windows and solaris trees. The GraphicsEnvironment implementations
are now responsible for initializing and setting the appropriate factory
in their static initializers. What do you think? I was thinking about a
different approach first, using yet another system property to determine
the right factory, but this seemed more natural.

Cheers, 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-0
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: 15278 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080226/3ffe23f1/patch.txt>

From Dmitri.Trembovetski at Sun.COM  Tue Feb 26 18:00:39 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Tue, 26 Feb 2008 10:00:39 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] SurfaceManagerFactory
In-Reply-To: <1204044836.7087.42.camel@mercury>
References: <1204044836.7087.42.camel@mercury>
Message-ID: <47C453C7.9060402@Sun.COM>


   Hi Roman,

   the change looks mostly fine to me.

   One thing - have you tested your change with the
   headless toolkit?

   Because it has its own GraphicsEnvironment class,
   and it would appear that you'd need to set appropriate
   SMF in there too.

   Now what would that "appropriate SMF" be is a question.
   I would suggest to return a BufImgVolatileSurfaceManager.

   I don't remember if it is present in jdk7 tree, but if it's
   not, it's just a simple subclass of VISM that returns
   null from initAccelSurface() and false from isAccelerationEnabled().

   Thanks,
     Dmitri

Roman Kennke wrote:
> Hello,
> 
> I'm implementing a Java2D backend based on Escher, which is already
> working quite well (for a couple-of-hours-prototype):
> 
> http://kennke.org/blog/2008/02/25/escher-on-openjdk-graphics/
> 
> One issue I came over is the SurfaceManagerFactory. There seems to be
> such a factory class both in the solaris and windows source trees, but
> no way to provide an own implementation. Therefore I propose the
> attached change. This basically turns the SurfaceManagerFactory into an
> abstract class, now in the shared tree, with appropriate subclasses in
> the windows and solaris trees. The GraphicsEnvironment implementations
> are now responsible for initializing and setting the appropriate factory
> in their static initializers. What do you think? I was thinking about a
> different approach first, using yet another system property to determine
> the right factory, but this seemed more natural.
> 
> Cheers, Roman
> 
> 


From roman.kennke at aicas.com  Tue Feb 26 19:08:34 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 26 Feb 2008 20:08:34 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] SurfaceManagerFactory
In-Reply-To: <47C453C7.9060402@Sun.COM>
References: <1204044836.7087.42.camel@mercury>  <47C453C7.9060402@Sun.COM>
Message-ID: <1204052914.7087.53.camel@mercury>

Hi Dmitri,

>    the change looks mostly fine to me.

Good!

>    One thing - have you tested your change with the
>    headless toolkit?

I haven't tested it, but it appears that in the headless case the
factory is never used anyway (from SunVolatileImage):

    protected VolatileSurfaceManager createSurfaceManager(Object
context, ImageCapabilities caps)
    {
        if (graphicsConfig instanceof BufferedImageGraphicsConfig ||
            graphicsConfig instanceof sun.print.PrinterGraphicsConfig ||
            (caps != null && !caps.isAccelerated()))
        {
            return new BufImgVolatileSurfaceManager(this, context);
        }
        SurfaceManagerFactory smf =
SurfaceManagerFactory.getInstance(); 
        return smf.createVolatileManager(this, context);
    }

This makes sense, because BufImgVolatileSurfaceManager is required for
all targets.

Cheers, 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-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Dmitri.Trembovetski at Sun.COM  Tue Feb 26 21:18:42 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Tue, 26 Feb 2008 13:18:42 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] SurfaceManagerFactory
In-Reply-To: <1204052914.7087.53.camel@mercury>
References: <1204044836.7087.42.camel@mercury> <47C453C7.9060402@Sun.COM>
	<1204052914.7087.53.camel@mercury>
Message-ID: <47C48232.50009@Sun.COM>

Roman Kennke wrote:
> 
> This makes sense, because BufImgVolatileSurfaceManager is required for
> all targets.

   Yep, you're right, that should cover it.

   I'd wait for another reviewer and if there are no
   objections we could integrate it.

   Thanks,
     Dmitri


From lists at munckfish.net  Thu Feb 28 12:22:55 2008
From: lists at munckfish.net (Dan Munckton)
Date: Thu, 28 Feb 2008 12:22:55 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
	Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <47B6219B.50005@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
	<1203114142.12409.2.camel@dylan>  <47B6219B.50005@Sun.COM>
Message-ID: <1204201375.10919.64.camel@dylan>

Hi Dmitri

On Fri, 2008-02-15 at 15:34 -0800, Dmitri Trembovetski wrote:
>    The good news is that we can probably integrate this fix into
>    the newly created 6open workspace so that the fix gets into
>    the major linux distros quickly.

Happily, I've been unable to recreate the weird mouse issue I noted on
any installation other than using a LiveCD build of Ubuntu. I'd really
like to get the patch into test builds to see what other people's
experience is with FSEM + Xorg 1.3, as I have limited hardware and OSes
here.

Is it worth trying to get the patch into the IcedTea versions first?

Is there anything else I can do to progress this for now?

Cheers

Dan



From Dmitri.Trembovetski at Sun.COM  Thu Feb 28 16:46:51 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Thu, 28 Feb 2008 08:46:51 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
 Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1204201375.10919.64.camel@dylan>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
	<1203114142.12409.2.camel@dylan> <47B6219B.50005@Sun.COM>
	<1204201375.10919.64.camel@dylan>
Message-ID: <47C6E57B.3050906@Sun.COM>


   Hi Dan,

   I have been preparing the fix for the integration into
   openjdk6.

   If you could put it into IcedTea that'd be beneficial
   as well in case someone runs into a problem.

   BTW, have you thought by any chance about the other part
   of the problem - proper xinerama detection? On the newer X
   servers we detect the xinerama extension (since it's always
   present and active), and assume that the screens are under
   xinerama. That leads to some nasty issues. I'm still not
   quite sure how to do the detection properly.

   Thanks,
     Dmitri

Dan Munckton wrote:
> Hi Dmitri
> 
> On Fri, 2008-02-15 at 15:34 -0800, Dmitri Trembovetski wrote:
>>    The good news is that we can probably integrate this fix into
>>    the newly created 6open workspace so that the fix gets into
>>    the major linux distros quickly.
> 
> Happily, I've been unable to recreate the weird mouse issue I noted on
> any installation other than using a LiveCD build of Ubuntu. I'd really
> like to get the patch into test builds to see what other people's
> experience is with FSEM + Xorg 1.3, as I have limited hardware and OSes
> here.
> 
> Is it worth trying to get the patch into the IcedTea versions first?
> 
> Is there anything else I can do to progress this for now?
> 
> Cheers
> 
> Dan
> 


From Dmitri.Trembovetski at Sun.COM  Thu Feb 28 16:55:54 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Thu, 28 Feb 2008 08:55:54 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
 Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <47C6E57B.3050906@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
	<1203114142.12409.2.camel@dylan> <47B6219B.50005@Sun.COM>
	<1204201375.10919.64.camel@dylan> <47C6E57B.3050906@Sun.COM>
Message-ID: <47C6E79A.5060005@Sun.COM>



Dmitri Trembovetski wrote:
> 
>   Hi Dan,
> 
>   I have been preparing the fix for the integration into
>   openjdk6.
> 
>   If you could put it into IcedTea that'd be beneficial
>   as well in case someone runs into a problem.
> 
>   BTW, have you thought by any chance about the other part
>   of the problem - proper xinerama detection? On the newer X
>   servers we detect the xinerama extension (since it's always
>   present and active), and assume that the screens are under
>   xinerama. That leads to some nasty issues. I'm still not
>   quite sure how to do the detection properly.

   My current version of the detection fix adds this check:
              xinInfo = (*XineramaQueryScreens)(awt_display, &locNumScr);
-            if (xinInfo != NULL) {
+            if (xinInfo != NULL && locNumScr > XScreenCount(awt_display)) {

@@ -699,11 +710,12 @@
              (XineramaGetCenterHintFunc*)dlsym(libHandle, XineramaGetCenterHintName);

          if (XineramaSolarisFunc != NULL) {
              DTRACE_PRINTLN("calling XineramaGetInfo func on Solaris");
              if ((*XineramaSolarisFunc)(awt_display, 0, &fbrects[0],
-                                       &fbhints[0], &locNumScr) != 0)
+                                       &fbhints[0], &locNumScr) != 0 &&
+                locNumScr > XScreenCount(awt_display))
              {
                  DTRACE_PRINTLN("Enabling Xinerama support");
                  usingXinerama = True;
                  /* set global number of screens */
                  DTRACE_PRINTLN1(" num screens = %i\n", locNumScr);

   The idea is that if xinerama is used XCountScreens should return 1,
   at the same time, if there's only one screen then we don't need
   to enable xinerama support either.

   But I'm still lacking proper environment to test this =(

   Thanks,
     Dmitri

> 
>   Thanks,
>     Dmitri
> 
> Dan Munckton wrote:
>> Hi Dmitri
>>
>> On Fri, 2008-02-15 at 15:34 -0800, Dmitri Trembovetski wrote:
>>>    The good news is that we can probably integrate this fix into
>>>    the newly created 6open workspace so that the fix gets into
>>>    the major linux distros quickly.
>>
>> Happily, I've been unable to recreate the weird mouse issue I noted on
>> any installation other than using a LiveCD build of Ubuntu. I'd really
>> like to get the patch into test builds to see what other people's
>> experience is with FSEM + Xorg 1.3, as I have limited hardware and OSes
>> here.
>>
>> Is it worth trying to get the patch into the IcedTea versions first?
>>
>> Is there anything else I can do to progress this for now?
>>
>> Cheers
>>
>> Dan
>>


From Dmitri.Trembovetski at Sun.COM  Thu Feb 28 19:53:13 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Thu, 28 Feb 2008 11:53:13 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
 Exclusive	Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <47C6E79A.5060005@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
	<1203114142.12409.2.camel@dylan> <47B6219B.50005@Sun.COM>
	<1204201375.10919.64.camel@dylan> <47C6E57B.3050906@Sun.COM>
	<47C6E79A.5060005@Sun.COM>
Message-ID: <47C71129.204@Sun.COM>


   OK, I have verified that my modified fix works correctly
   in the following configurations:
    Ubuntu Hardy Herron a5
     two separate screen, no xinerama extension => we detect no xinerama (and full-screen mode supported)
     two screens + xinerama active => we detect xinerama (fs mode unsupported)
     single screen + xinerama ext. => we don't xinerama (fs mode supported)

   The only configuration left to test is two separate screens
   with xinerama extension present - but not "used"
   so you can't drag windows from one screen to another.
   I believe this is when we had issues.

   I can't enable such configuration on my nvidia-accelerated
   server for some reason. I'll install solaris nevada x86 and
   see if that would work.

   Thanks,
     Dmitri


Dmitri Trembovetski wrote:
> 
> 
> Dmitri Trembovetski wrote:
>>
>>   Hi Dan,
>>
>>   I have been preparing the fix for the integration into
>>   openjdk6.
>>
>>   If you could put it into IcedTea that'd be beneficial
>>   as well in case someone runs into a problem.
>>
>>   BTW, have you thought by any chance about the other part
>>   of the problem - proper xinerama detection? On the newer X
>>   servers we detect the xinerama extension (since it's always
>>   present and active), and assume that the screens are under
>>   xinerama. That leads to some nasty issues. I'm still not
>>   quite sure how to do the detection properly.
> 
>   My current version of the detection fix adds this check:
>              xinInfo = (*XineramaQueryScreens)(awt_display, &locNumScr);
> -            if (xinInfo != NULL) {
> +            if (xinInfo != NULL && locNumScr > 
> XScreenCount(awt_display)) {
> 
> @@ -699,11 +710,12 @@
>              (XineramaGetCenterHintFunc*)dlsym(libHandle, 
> XineramaGetCenterHintName);
> 
>          if (XineramaSolarisFunc != NULL) {
>              DTRACE_PRINTLN("calling XineramaGetInfo func on Solaris");
>              if ((*XineramaSolarisFunc)(awt_display, 0, &fbrects[0],
> -                                       &fbhints[0], &locNumScr) != 0)
> +                                       &fbhints[0], &locNumScr) != 0 &&
> +                locNumScr > XScreenCount(awt_display))
>              {
>                  DTRACE_PRINTLN("Enabling Xinerama support");
>                  usingXinerama = True;
>                  /* set global number of screens */
>                  DTRACE_PRINTLN1(" num screens = %i\n", locNumScr);
> 
>   The idea is that if xinerama is used XCountScreens should return 1,
>   at the same time, if there's only one screen then we don't need
>   to enable xinerama support either.
> 
>   But I'm still lacking proper environment to test this =(
> 
>   Thanks,
>     Dmitri
> 
>>
>>   Thanks,
>>     Dmitri
>>
>> Dan Munckton wrote:
>>> Hi Dmitri
>>>
>>> On Fri, 2008-02-15 at 15:34 -0800, Dmitri Trembovetski wrote:
>>>>    The good news is that we can probably integrate this fix into
>>>>    the newly created 6open workspace so that the fix gets into
>>>>    the major linux distros quickly.
>>>
>>> Happily, I've been unable to recreate the weird mouse issue I noted on
>>> any installation other than using a LiveCD build of Ubuntu. I'd really
>>> like to get the patch into test builds to see what other people's
>>> experience is with FSEM + Xorg 1.3, as I have limited hardware and OSes
>>> here.
>>>
>>> Is it worth trying to get the patch into the IcedTea versions first?
>>>
>>> Is there anything else I can do to progress this for now?
>>>
>>> Cheers
>>>
>>> Dan
>>>


From roman.kennke at aicas.com  Fri Feb 29 12:26:03 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 29 Feb 2008 13:26:03 +0100
Subject: [OpenJDK 2D-Dev] Portable GUI backends
Message-ID: <1204287964.10390.60.camel@mercury>

Hi,

(sorry for x-posting, but I think this affects all 3 lists.)

I'd like to point you to my proposal for the OpenJDK Innovators
Challenge, which aims to improve the design of AWT, Java2D and Swing,
such that it is possible to implement new (external) backends for AWT
and Java2D:

http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/000045.html

I'd like to hear your opinion on that proposal. The proposal phase ends
on march, 2nd, I will send the final proposal then, so if you have a
good suggestion for improvement, I'd be happy if you could post it today
or tomorrow (in reply to the proposal, not this email please).

Thanks alot and cheers, 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-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From lists at munckfish.net  Fri Feb 29 14:08:00 2008
From: lists at munckfish.net (Dan Munckton)
Date: Fri, 29 Feb 2008 14:08:00 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java
	Fullscreen	Exclusive	Mode not working with Xorg server 1.3.0
	and above
In-Reply-To: <47C71129.204@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
	<1203114142.12409.2.camel@dylan> <47B6219B.50005@Sun.COM>
	<1204201375.10919.64.camel@dylan> <47C6E57B.3050906@Sun.COM>
	<47C6E79A.5060005@Sun.COM>  <47C71129.204@Sun.COM>
Message-ID: <1204294080.23914.9.camel@dylan>

Hi

Sorry haven't had time to test your patch here yet. But I did notice
that only Xinerama seems to report the correct number of screens -
XScreenCount(...) returns 1 whether I've got 1 or 2 monitors plugged in.

>    The only configuration left to test is two separate screens
>    with xinerama extension present - but not "used"
>    so you can't drag windows from one screen to another.
>    I believe this is when we had issues.
> 
>    I can't enable such configuration on my nvidia-accelerated
>    server for some reason. I'll install solaris nevada x86 and
>    see if that would work.
> 

Yeah I believe this is what's known as "old style dual head mode" isn't
it? I couldn't get this working on my setup either.

Cheers

Dan



From Dmitri.Trembovetski at Sun.COM  Fri Feb 29 15:48:58 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 29 Feb 2008 07:48:58 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469:
 Java	Fullscreen	Exclusive	Mode not working with Xorg server 1.3.0	and above
In-Reply-To: <1204294080.23914.9.camel@dylan>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
	<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
	<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
	<1203114142.12409.2.camel@dylan> <47B6219B.50005@Sun.COM>
	<1204201375.10919.64.camel@dylan> <47C6E57B.3050906@Sun.COM>
	<47C6E79A.5060005@Sun.COM> <47C71129.204@Sun.COM>
	<1204294080.23914.9.camel@dylan>
Message-ID: <47C8296A.1080405@Sun.COM>


   Hi Dan,

Dan Munckton wrote:
> Sorry haven't had time to test your patch here yet. But I did notice
> that only Xinerama seems to report the correct number of screens -
> XScreenCount(...) returns 1 whether I've got 1 or 2 monitors plugged in.

   Yes, that's what I'm hoping for. XScreenCount is supposed
   to return 1 if xinerama is enabled.

   As I understand, the configuration where some screens
   are 'joined' via xinerama, and some aren't, isn't
   supported.

>>    The only configuration left to test is two separate screens
>>    with xinerama extension present - but not "used"
>>    so you can't drag windows from one screen to another.
>>    I believe this is when we had issues.
>>
>>    I can't enable such configuration on my nvidia-accelerated
>>    server for some reason. I'll install solaris nevada x86 and
>>    see if that would work.
>>
> 
> Yeah I believe this is what's known as "old style dual head mode" isn't
> it? I couldn't get this working on my setup either.

   This is an "old style" with a twist. Prior to Xorg 1.3
   the xinerama extension wouldn't be "active" if you had
   multiple screens but xinerama was not enabled.

   But now it is, apparently - at least in some situations,
   which is the cause of
     6599351: javaws only runs in the left-hand screen on snv_71

   In this bug users had dual screen setup, w/o
   xinerama explicitly enabled, but we were detecting xinerama and
   assuming there's a single X screen, which lead to issues.

   Thanks,
    Dmitri


From Dmitri.Trembovetski at Sun.COM  Fri Feb 29 17:36:07 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 29 Feb 2008 09:36:07 -0800
Subject: [OpenJDK 2D-Dev] Portable GUI backends
In-Reply-To: <1204287964.10390.60.camel@mercury>
References: <1204287964.10390.60.camel@mercury>
Message-ID: <47C84287.1020508@Sun.COM>


   Hi Roman,

   this looks like a good proposal. Won't be easy, but
   it would be nice to have a clear separation between
   the interfaces and the implementation.

   Thanks,
     Dmitri

Roman Kennke wrote:
> Hi,
> 
> (sorry for x-posting, but I think this affects all 3 lists.)
> 
> I'd like to point you to my proposal for the OpenJDK Innovators
> Challenge, which aims to improve the design of AWT, Java2D and Swing,
> such that it is possible to implement new (external) backends for AWT
> and Java2D:
> 
> http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/000045.html
> 
> I'd like to hear your opinion on that proposal. The proposal phase ends
> on march, 2nd, I will send the final proposal then, so if you have a
> good suggestion for improvement, I'd be happy if you could post it today
> or tomorrow (in reply to the proposal, not this email please).
> 
> Thanks alot and cheers, Roman
> 


From linuxhippy at gmail.com  Fri Feb 29 17:47:44 2008
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 29 Feb 2008 18:47:44 +0100
Subject: [OpenJDK 2D-Dev] DRAFT PROPOSAL: Implement XRender pipeline for
	Java2D
Message-ID: <194f62550802290947o600adab5x66e2fd0c1026eac@mail.gmail.com>

Hi,

Also sorry for cross-posting, I thought it wouldn't be a bad idea to
let you guys on the 2d-dev list know about my proposal. Sorry for the
traffic.

I would be very happy about suggestions and ideas howto enhance the
proposal as well as maybe some patronage at
challenge-discuss at openjdk.java.net.
I have to admit the best that I could imagine is something like a
supporter directly from Sun, like  what "Charles Oliver Nutter" did
for the Better-native-Interface-Proposal ;)

Thanks for reading, lg Clemens

---------------------------------------------------------------------------------------
1.) Introduction
The more advanced features of Java2D are used in a lot new key
technologies like JavaFX, Nimbus, SVG, Arith and even native Swing
themes like the GtkLookAndFeel and without any doubt their use will
grow further.
Since its introduction, Java2D supports very advanced rendering
operations, although only very basic operations were accelerated by
hardware, because the underlying APIs were very poor.
However software-rendering leads to low performance and bad user
experience in this case.

Modern 3D graphic APIs, like OpenGL or Direct3D, allow to map most of
Java2D's functionality without the need for expensive read-backs
and/or software rendering.
To make that functionality available to the Java platform two new
?pipelines" where created:
The OpenGL pipeline for non Windows platforms, and the Direct3D
pipeline for the Microsoft Windows operating systems only.
However OpenGL on Unix in general has some disadvantages compared to
X11 for typical desktop applications, because of poor drivers its
often not possible to use that new functionality and Java falls back
to the default X11 rendering pipeline.

An Xrender backend for Java2D would provide almost the same features
as the existing OpenGL pipeline, however would run on a much larger
set of hardware and would integrate better into existing X11 based
desktops.
With the Xrender backend developers and users could rely on almost the
same set of functionality accelerated by default on all platforms
supported currently by OpenJDK, e.g. JavaFX animations could run at
almost the same speed everywhere.


2.) Status Quo
The existing X11 pipeline used on Unix systems is only capable of
accelerating basic operations and falls back to software rendering
even for often used operations like antialiasing (even for text!) or
translucent images often causing expensive VRAM readbacks.
Because of X11's very limited rendering capabilities Xrender was
introduced back in 2001, and after a long delay first drivers are
available which accelerate large areas of Xrender.

XRender allows to accelerate most of Java2D's functionality, and it is
considered to be the de-facto standard for advanced 2D graphics,
already used by a large set of libraries and toolkits like Cairo,
GTK+, QT4 and KDE4.
Because of the broad and extensive use of Xrender there is currently
major work ongoing to modify drivers for better Xrender performance.

There is already an OpenGL backend for Java2D which is about as
powerful as its Direct3D counterpart on Windows.
Unlike on Windows where Microsoft starting with Windows Vista
more or less deprecated all interfaces except Direct3D, and therefor
forces GPU/driver manufacturers to create drivers well suited also for
2D rendering, on Unix good
OpenGL drivers are still rare and only proprietary drivers are till
now able to run the OpenGL pipeline.
However those proprietary drivers are often optimized for heavy-weight 3D
applications like games and are not really suited for rendering
light-weight simple 2D applications.

A small overview about the advantages/disadvantages Xrender has
compared to OpenGL:

+ Lower per-primitive overhead:
Because Xrender is compared to OpenGL a lot simpler, there is less
work for the accelerating driver to do for each primitive rendering
operation. This is especially important for complex shapes which are
transformed to many rectangles which then are passed to the underlying
graphic API.
To make it short: Because Xrender focuses on only a small set of
?simple" operations, driver implementers can focus on making those few
operations as fast as possible.

+ Support for higher-level primitives:
Xrender has support for client-side font rendering, which means glyphs
which are cached in vram can be shared across different applications.
For OpenGL each application has to upload its glyphs into a private
texture wasting large amounts of Vram.
Because it was designed with 2D graphics in mind many features can be
directly mapped to Xrender without the need of complex shaders.

+ Reliable AntiAliasing:
Because Xrender specifies exactly how antialiasing has to be done,
Java2D can rely on Xrender's antialiasing capabilities. The Direct3D
and OpenGL pipelines render a alpha-mask in software, upload it to
vram and only let the GPU only do the final composition step.
Because of this, the amount of data transferred between the Xserver
and the Java application would be reduced a lot, making antialising
even usable over slow remote connections.

+ Better driver support:
On Linux only proprietary OpenGL implementations provide enough
functionality to let the OpenGL pipeline run. However even those
proprietary drivers were/are buggy in the code-paths exercised by the
OpenGL pipeline - sometimes new drivers even broke the OpenGL
pipeline.
For Xrender there are already many optimized drivers, both open-source
(Intel, ATI, ...) and proprietary (Nvidia). Because of the high
adaption rate of Xrender lately (KDE4, Cairo, GTK+, ...) it can be
expected that soon more and more drivers will support Xrender
acceleration.

+ Better desktop integration:
Xrender applications are ?native" X11 applications, and therefor work
well with composition managers. They also get visuals optimized for
2D, and do not waste Vram with additional buffers they get, although
they are not used.

+ Better network transparency:
Although OpenGL can also be made network-transparent via GLX, the
OpenGL API was not designed to perform especially well in a network
environment.
X11/XRender relies on the Client-Server approach and therefor is
optimized for exactly this case.

- Not programmable:
A disadvantage of Xrender is that its not as flexible as OpenGL.
OpenGL allows to use shaders to implement features not provided by
fixed functionality, the only solution for a Xrender based backend is
to fall back to software rendering.


3.) Goals
The goal of this proposal is to make use of Xrender for accelerating
even advanced Java2D functionality.
This would allow multimedia applications/content like JavaFX to take
advantage of modern hardware, and would bring JDK6Update10 graphic
features also to X11/Unix based platforms.

Some of the most important enhancements compared to the X11 pipeline include:
* Accelerated text rendering for normal, antialiased and subpixel
antialiased text.
* Support for translucent images
* Composition (colors with alpha values, ...)
* Antialiasing

A long-term goal would be to make the existing X11 pipeline obsolete
once the XRender backend has prooven to be stable, removing the burden
of maintaining two, in their dedication similar, backends.


4.) Approach
XRender has a lot in common with OpenGL/Direct3D and is a very
low-level API which supports only a limited number of drawing
primitives but it is very flexible in the way of operations it
operates with those operations. Therefor the approach would be to
create a brand new backend based on the shared code developed for the
OpenGL/Direct3D pipelines in JDK6-u10.
The advantage of this approach would be a ?clean start", as well as a
lot shared code between OpenGL/Direct3D/XRender backends.
The downside is that some highly optimized primitives which are
supported by X11's core drawing (Arcs, Elipses, ..) maybe perform a
little bit less well. Furthermore new code needs a lot of testing.


5.) Milestones
5.1) Create a skeleton which is able to use the shared OpenGL/Direct3D code
5.2) Implement only enough to functionality to make
software-rendering-loops work.
5.3) Extend the created skeleton, accelerate basic operations -> Make
typical Swing/Ocean applications work well.
5.4) Accelerate more advanced functionality like gradients,
composition and antialising -> Accalerate most of Java2Demo, make the
Nimbus LnF work well.
5.5) Extensive profiling and compatibility testing, using self
written, Sun's jtreg and real- world tests, reporting performance and
implementation problems back to driver programmers. Make sure large
graphical applications work well.


6.) Developer
Clemens Eisserer is Student at the Technical University of Vienna
(Information Technology) and:
* Has submitted patches and regression tests to jdk-collaboration
(plugin, webstart) and OpenJDK (Java2D, Corelibs)
* Implemented JLayeredPane for SwingWT: http://swingwt.sourceforge.net/
* Ported Kaffe's XAWT to GCJ: http://sf.net/projects/xawt
* Is working on an open-source remote-swing project:
http://juibrowser.sourceforge.net/
* Compiled and packaged a free JVM for the Nokia770 internet tablet.
* Is working on enhancing GTK's theme API and later on adapting
GtkLookAndFeel to take advantage of those enhancements:
http://bugzilla.gnome.org/show_bug.cgi?id=515600
* Finished some commercial projects written in Java with focus on
client-server architectures


7.) Links, References, ...
http://keithp.com/~keithp/render/
http://www.nabble.com/Best-way-organizing-XRender-additions-for-the-X11-pipeline--td14152122.html
http://www.phoronix.com/scan.php?page=article&item=934&num=1
http://bugs.sun.com/view_bug.do?bug_id=5086814 (RFE: Java 2D: consider
Xrender for anti-aliased text on remote X11)
http://bugs.sun.com/view_bug.do?bug_id=6307603 ([X11] Use RENDER
extension for complex operations done in software)