From mark at klomp.org  Fri Nov 28 14:44:06 2008
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 28 Nov 2008 23:44:06 +0100
Subject: X11GraphicsDevice.makeConfigurations()
Message-ID: <1227912246.22499.31.camel@hermans.wildebeest.org>

Hi,

I was reading the code and saw that
X11GraphicsDevice.makeConfigurations() has:

      boolean xrender = X11GraphicsEnvironment.isXRenderAvailable();

      if(!xrender) 
      { 
          ret[i] = XRGraphicsConfig.getConfig(this, visNum, depth, 
                            getConfigColormap(i, screen), 
                            doubleBuffer); 
      }else 
      { 
          ret[i] = X11GraphicsConfig.getConfig(this, visNum, depth, 
                   getConfigColormap(i, screen), 
                   doubleBuffer); 
      } 

Isn't this backwards? 

makeDefaultConfiguration() has it as follows:

      if(X11GraphicsEnvironment.isXRenderAvailable())
      {
              System.out.println("XRender pipeline enabled");
          defaultConfig = XRGraphicsConfig.getConfig(this, visNum,
                  depth, getConfigColormap(0, screen),
                  doubleBuffer);
       }else
       {
          defaultConfig = X11GraphicsConfig.getConfig(this, visNum,
                  depth, getConfigColormap(0, screen),
                  doubleBuffer);
       }

Cheers,

Mark



From mark at klomp.org  Sat Nov 29 08:58:34 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 29 Nov 2008 17:58:34 +0100
Subject: isX11SurfaceDataInitialized
Message-ID: <1227977914.3490.7.camel@dijkstra.wildebeest.org>

Hi,

The isX11SurfaceDataInitialized field and new public static accessor
methods in X11GraphicsEnvironment confused me a bit at first, because it
has the X11SurfaceData and XRSurfaceData classes calling back into the
X11GraphicsEnvironment class. While not incorrect I was wondering why
not just use the static class initialization method that X11SurfaceData
was using to make sure it is only initialized once. I found the original
code easier to understand. But maybe I am missing something in the
initialization chain?

Cheers,

Mark



From linuxhippy at gmail.com  Sat Nov 29 10:23:22 2008
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 29 Nov 2008 19:23:22 +0100
Subject: X11GraphicsDevice.makeConfigurations()
In-Reply-To: <1227912246.22499.31.camel@hermans.wildebeest.org>
References: <1227912246.22499.31.camel@hermans.wildebeest.org>
Message-ID: <194f62550811291023h59ea3aa2yd2cb8649c628f0f3@mail.gmail.com>

Hi Mark,

Thanks for reading through the code.
Yes seems I mixed that up.

Thanks again,  Clemens

2008/11/28 Mark Wielaard <mark at klomp.org>:
> Hi,
>
> I was reading the code and saw that
> X11GraphicsDevice.makeConfigurations() has:
>
>      boolean xrender = X11GraphicsEnvironment.isXRenderAvailable();
>
>      if(!xrender)
>      {
>          ret[i] = XRGraphicsConfig.getConfig(this, visNum, depth,
>                            getConfigColormap(i, screen),
>                            doubleBuffer);
>      }else
>      {
>          ret[i] = X11GraphicsConfig.getConfig(this, visNum, depth,
>                   getConfigColormap(i, screen),
>                   doubleBuffer);
>      }
>
> Isn't this backwards?
>
> makeDefaultConfiguration() has it as follows:
>
>      if(X11GraphicsEnvironment.isXRenderAvailable())
>      {
>              System.out.println("XRender pipeline enabled");
>          defaultConfig = XRGraphicsConfig.getConfig(this, visNum,
>                  depth, getConfigColormap(0, screen),
>                  doubleBuffer);
>       }else
>       {
>          defaultConfig = X11GraphicsConfig.getConfig(this, visNum,
>                  depth, getConfigColormap(0, screen),
>                  doubleBuffer);
>       }
>
> Cheers,
>
> Mark
>
>


From mark at klomp.org  Sat Nov 29 10:52:55 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 29 Nov 2008 19:52:55 +0100
Subject: allowShmPixmaps
Message-ID: <1227984775.3490.12.camel@dijkstra.wildebeest.org>

Hi,

XShared_initIDs has a new argument allowShmPixmaps. As far as I can see
it is always passed in as JNI_TRUE. Is there a reason you would want to
force it to false?

Cheers,

Mark



From linuxhippy at gmail.com  Sat Nov 29 11:11:43 2008
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 29 Nov 2008 20:11:43 +0100
Subject: Fwd: allowShmPixmaps
In-Reply-To: <194f62550811291111v1a3e554fk9e3902d1fbbf64ac@mail.gmail.com>
References: <1227984775.3490.12.camel@dijkstra.wildebeest.org>
	<194f62550811291111v1a3e554fk9e3902d1fbbf64ac@mail.gmail.com>
Message-ID: <194f62550811291111t4cbb8da5if522b0ae3c2ad7b2@mail.gmail.com>

Hi Mark,

Its always JNI_TRUE when it is called from within the X11 pipeline,
but when called from the XRender pipeline (
Java_sun_java2d_xr_XRSurfaceData_initIDs ) SHMPixmaps are disabled.

The reason is that SHMPixmaps are ususally a bad if you would like
them accalerated by the driver, because they cause pixmaps to be bound
to system-memory usually - however the X11 pipeline relies on it for
good performance when mixing server/client rendering.
However SHMPixmaps are not supported by EXA based drivers and the
latest NVidia beta release also disables them by default, so usually
we won't get them anyway ;)

By the way, I intend to rewrite the whole MaskBuffer stuff soon, as
well as large amounts of the C code.
I am not really used to C, so sorry if the code is quite ugly in some cases.

- Clemens


From mark at klomp.org  Sat Nov 29 12:16:26 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 29 Nov 2008 21:16:26 +0100
Subject: Fwd: allowShmPixmaps
In-Reply-To: <194f62550811291111t4cbb8da5if522b0ae3c2ad7b2@mail.gmail.com>
References: <1227984775.3490.12.camel@dijkstra.wildebeest.org>
	<194f62550811291111v1a3e554fk9e3902d1fbbf64ac@mail.gmail.com>
	<194f62550811291111t4cbb8da5if522b0ae3c2ad7b2@mail.gmail.com>
Message-ID: <1227989786.20040.11.camel@hermans.wildebeest.org>

Hi Clemens,

On Sat, 2008-11-29 at 20:11 +0100, Clemens Eisserer wrote:
> Its always JNI_TRUE when it is called from within the X11 pipeline,
> but when called from the XRender pipeline (
> Java_sun_java2d_xr_XRSurfaceData_initIDs ) SHMPixmaps are disabled.

O, right, sorry I missed that.

> The reason is that SHMPixmaps are ususally a bad if you would like
> them accalerated by the driver, because they cause pixmaps to be bound
> to system-memory usually - however the X11 pipeline relies on it for
> good performance when mixing server/client rendering.
> However SHMPixmaps are not supported by EXA based drivers and the
> latest NVidia beta release also disables them by default, so usually
> we won't get them anyway ;)

Aha. I am still learning lots of how the (accelerated) X11 pipelines
work.

> By the way, I intend to rewrite the whole MaskBuffer stuff soon, as
> well as large amounts of the C code.
> I am not really used to C, so sorry if the code is quite ugly in some cases.

You seem to do fine. It is really exciting work. Not only do java2d
programs work faster, they actually are usable over a remote X
connection now.

I was just going over the code to see if I understood how the separation
between X11 and XR was setup, to convince myself that the old pipeline
isn't changed in any way when the xrender pipeline isn't activated.

Cheers,

Mark



From mark at klomp.org  Sun Nov 30 03:43:53 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 30 Nov 2008 12:43:53 +0100
Subject: Xrender pipeline support merged into IcedTea6
Message-ID: <1228045433.4178.36.camel@dijkstra.wildebeest.org>

Hi,

As most of you probably know Clemens Eisserer has been working on an
alternative X11 rendering pipeline based on Xrender [1]. Although still
a work in progress the results are already stunning. Lots of Java2D
using applications are noticably faster (sometimes by a factor of 10!)
and running over a remote X connection now feels like it is all local.

Clemens has been pushing bug reports against the whole graphics stack
(graphics drivers, Xorg server, etc) to get it improved and I believe
his work is really pushing performance enhancements all over. I am
hoping that by including xrender as a default option in IcedTea and
being adopted by the various GNU/Linux distros these enhancements will
be accelerated.

The new Xrender pipeline is completely optional. If a user doesn't
activate it (-Dsun.java.xrender=True) then the old X11 pipeline is being
used. This makes it safe to include by default. With this more people
will be able to test it out and detect performance bottlenecks still
present. Clemens blog is a good source of information for those wanting
to test it out and getting more background on the underlying
technologies that make it all work (fast) [2].

Backporting to IcedTea6 was pretty easy. It depends on Roman's extension
to make the SurfaceManagerFactory allow plugging in different
implementations (included as icedtea-xrender-000.patch) and only the
initial drop (icedtea-xrender-001.patch) needed some adjustments to
apply cleanly. That patch also includes one minor bug fix [3]. The rest
of the included patches (icedtea-xrender-00[2-8].patch) are just the
commulative patches drawn from the xrender repository [4]. This should
make it easy to keep it up to date from the master repository by just
adding a new icedtea-xrender-xxx+1.patch for each new commit.

configure.ac and Makefile.am have been extended to check for
--enable-xrender (default yes) and the Xrender libraries and only apply
the patches when both are there.

2008-11-29  Mark Wielaard  <mark at klomp.org>

        * configure.ac: Add and check --enable-xrender.
        * Makefile.am: Add XRENDER_PATCHES when ENABLE_XRENDER set.
        * patches/icedtea-xrender-00[0-8].patch: New patches.
        * HACKING: Document new patches.

Changes applied attached (excluding the icedtea-xrender-xxx.patch
files).

Cheers,

Mark

[1]
http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-March/000054.html
[2]
http://linuxhippy.blogspot.com/
[3]
http://mail.openjdk.java.net/pipermail/xrender-dev/2008-November/000011.html
[4]
http://hg.openjdk.java.net/xrender/xrender/jdk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xrender.patch
Type: text/x-patch
Size: 2105 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/xrender-dev/attachments/20081130/d972f4dd/attachment.bin 

From linuxhippy at gmail.com  Sun Nov 30 12:33:44 2008
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sun, 30 Nov 2008 21:33:44 +0100
Subject: Xrender pipeline support merged into IcedTea6
In-Reply-To: <1228045433.4178.36.camel@dijkstra.wildebeest.org>
References: <1228045433.4178.36.camel@dijkstra.wildebeest.org>
Message-ID: <194f62550811301233t3f68b90eg35e515a3711e385@mail.gmail.com>

Hi Mark,

Wow, this is _really_ cool news, thanks a lot :)
I had already thought about asking for integration at a later time, to
allow some kind of slow adoption by interested testers, but seeing it
actually happening is extremly great.

Thanks for your hard work integrating it and for your useful comments
and bug-reports.

Thanks again, Clemens

2008/11/30 Mark Wielaard <mark at klomp.org>:
> Hi,
>
> As most of you probably know Clemens Eisserer has been working on an
> alternative X11 rendering pipeline based on Xrender [1]. Although still
> a work in progress the results are already stunning. Lots of Java2D
> using applications are noticably faster (sometimes by a factor of 10!)
> and running over a remote X connection now feels like it is all local.
>
> Clemens has been pushing bug reports against the whole graphics stack
> (graphics drivers, Xorg server, etc) to get it improved and I believe
> his work is really pushing performance enhancements all over. I am
> hoping that by including xrender as a default option in IcedTea and
> being adopted by the various GNU/Linux distros these enhancements will
> be accelerated.
>
> The new Xrender pipeline is completely optional. If a user doesn't
> activate it (-Dsun.java.xrender=True) then the old X11 pipeline is being
> used. This makes it safe to include by default. With this more people
> will be able to test it out and detect performance bottlenecks still
> present. Clemens blog is a good source of information for those wanting
> to test it out and getting more background on the underlying
> technologies that make it all work (fast) [2].
>
> Backporting to IcedTea6 was pretty easy. It depends on Roman's extension
> to make the SurfaceManagerFactory allow plugging in different
> implementations (included as icedtea-xrender-000.patch) and only the
> initial drop (icedtea-xrender-001.patch) needed some adjustments to
> apply cleanly. That patch also includes one minor bug fix [3]. The rest
> of the included patches (icedtea-xrender-00[2-8].patch) are just the
> commulative patches drawn from the xrender repository [4]. This should
> make it easy to keep it up to date from the master repository by just
> adding a new icedtea-xrender-xxx+1.patch for each new commit.
>
> configure.ac and Makefile.am have been extended to check for
> --enable-xrender (default yes) and the Xrender libraries and only apply
> the patches when both are there.
>
> 2008-11-29  Mark Wielaard  <mark at klomp.org>
>
>        * configure.ac: Add and check --enable-xrender.
>        * Makefile.am: Add XRENDER_PATCHES when ENABLE_XRENDER set.
>        * patches/icedtea-xrender-00[0-8].patch: New patches.
>        * HACKING: Document new patches.
>
> Changes applied attached (excluding the icedtea-xrender-xxx.patch
> files).
>
> Cheers,
>
> Mark
>
> [1]
> http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-March/000054.html
> [2]
> http://linuxhippy.blogspot.com/
> [3]
> http://mail.openjdk.java.net/pipermail/xrender-dev/2008-November/000011.html
> [4]
> http://hg.openjdk.java.net/xrender/xrender/jdk/
>


From linuxhippy at gmail.com  Sun Nov 30 13:25:00 2008
From: linuxhippy at gmail.com (linuxhippy at gmail.com)
Date: Sun, 30 Nov 2008 21:25:00 +0000
Subject: hg: xrender/xrender/jdk: - Improved performance of non-solid
	operations
Message-ID: <20081130212529.EDC48DE4D@hg.openjdk.java.net>

Changeset: c72b1c0435c0
Author:    ceisserer
Date:      2008-11-30 22:14 +0100
URL:       http://hg.openjdk.java.net/xrender/xrender/jdk/rev/c72b1c0435c0

- Improved performance of non-solid operations
- Improved performance of GPUs not supporting A8+A8 composition, but are capable of XCopyArea'ing with A8->A8 with their 2D engines (i830, GF6/7)
- X11/XR pipeline initialization in X11GraphicsDevice was mixed up

! src/solaris/classes/sun/awt/X11GraphicsDevice.java
! src/solaris/classes/sun/java2d/xr/XRMaskFill.java
! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java
! src/solaris/native/sun/java2d/x11/MaskBuffer.c