DRAFT PROPOSAL: Port of „Consumer JRE“ features to Unix/X11 platforms

[Clemens Eisserer]

Hi again,

Below is an early version of my Draft Proposal.

There are some open questions like:
- Is it possible to write code-parts for other projects (GTK+) in this
cause if OpenJDK would benefit, and its not possible to work arround
these problems in OpenJDK?
I am a bit afraid that my code would not be included in GTK not
because of technical problems but rather because of ideological or
just because nobody is interested in reviewing it - so would it be
still be sucessful if I point that out?
- I am an Austrian citizen which is not on the list of allowed
countries. Hope this can be fixed.

I would be happy about comments, spelling mistakes or sections I
should formulate more detailed - so if you have any suggestions please
let me know.
How important is it to get an recommendation from anuniversity
professor or researcher?

Port of „Consumer JRE" features to Unix/X11 platforms


1.) Introcuction
Since the release of Java-5 many improvements have been made in order
to make the JAVA platform better suited for deskop use. With the
release of Java6_update10 many exciting, new, and very useful features
will be available for  desktop users which use the Windows operating
system.
However, because many of the changes are very platform specific like
the new Direct3d-9 Java2d pipeline many improvements can not be ported
easily to other operating systems like Solaris and Linux.
The aim of the proposal would be to start a project which ports many
of those platform sepcific enhancements to X11 based Unix platforms in
an as portable as possible manner.

2.) Goals
This would allow developers to rely on the same set of features and
the same level of implementation quality across whole set of platforms
supported by Java, instead  of cutting for example visual appearance
down on one platform because of performance problems.
Users would be able to run applications across all of their platforms
and could enjoy the same  behaviour and performance.

A detailed list of changes would be:

Port the Java-Quick-Starter (JQS) to Linux (and if possible to other
Unix operating systems as well)

Implement a new Java2D backend which utilizes the Xrender extension
provided by modern implementations of the X11 standard.

Enhance GTK+ to make it more suitable for themeing

Extend the GTKLookAndFeel to use the improved theming interface of GTK+


2.1)  Java-Quick-Starter (JQS) for Unix:
The Java-Quick-Starter is part of JDK6_u10 and keeps files which are
typically used at JRE startup in memory (if the computer is not
running on battery).
Although the code is not open till now it should not be too hard to
port the existing code to Unix and refactor out all platform specific
details.

Because Linux/Solaris are more and more used on desktops, a fast
cold-start is as important as for Windows users. Furthermore a fast
cold-start could help to improve the reputation of Java on those
platforms of starting slow which could help to improve the adaption
rate of the open-source community.

Sun dependence: A 1:1 port would require the JDK6-u10 source code to
be released, or at least be opend for the developer(s) working on this
project if the code is intended to be released later.
If the code is not planned to be released anytime soon it would not be
too hard to write a new quickstarter for Unix – however it would not
be possible to base both on a common codebase which could make
maintenance simpler.


2.2 Java2D Xrender backend:
Also with JDK-u10 a new Java2D backend will be introduced based on Direct3D-9.
A very powerful OpenGL backend is available on all supported platforms
which shares a lot common code with the Direct3D based pipeline.

The X11 pipeline used mainly on Unix systems is only capable of
accalerating basic operations and falls back to software rendering for
anything from antialiased text to translucent images sometimes causing
expensive VRAM readbacks.
However unlike Windows where Microsoft starting with Windows Vista
more or less deprecated all interfaces except Direct3D, on Unix good
OpenGL drivers are still rare and only proprietary drivers are till
now able to run the OpenGL pipeline.
Even 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. Furthermore, although GLX exists,
remote support is not as great as it could be.
Because of those problems the OpenGL pipeline won't be able in the
short term to step in as a replacement for the existing X11 pipeline.

The XRender design has a lot in common with OpenGL/Direct3D, so one of
two possible implementations would be to create a brand new backend
based on the shared code developed for the OpenGL/Direct3D pipelines
in JDK6-u10, however this would require Sun to release this part of
code or at least send it to the developer(s) if its opening is
planned.
If this approach would not be successful an extension to the current
X11 pipeline could be developed which could address the current
shortcomings but rely on X-Core-Drawing  for already implemented
functionality.


2.3) Enhance GTK+ to make it more suitable for themeing:

GTK+ drawing functionality is limited to drawing on X11-server-side
resources, however the GtkLookAndFeel would need the data on the
client-side.
Furthermore things have to be drawn twice and compared in a costly
operation to determine transparent/translucent parts of the resulting
image, which means many client/server roundtrips per drawn widget (if
not cached) and CPU expensive operations.

A solution would be a new theming API which would allow to pass a
cairo-drawing-context to GTK, and if the installed theme supports the
new API, all operations could be done on an system-memory surface,
with cairo even preserving the transparent/translucent parts.

Note: This code itself is not targeted to OpenJDK but to the GTK+
project. However if it could be donated to Sun/OpenJDK which would
also support (in the term of saying OpenJDK would favour the
integration) the integration of the new code it could make acceptance
of the new code much better.


2.4) Extend the GTKLookAndFeel to use the improved theming interface of GTK+

The existing GTKLookAndFeel would need an adaption to take advantake
of the new theming interface mentioned above as well as a
fallback-mechanism in the case that:
the installed version of GTK+ does not support the new theme API
the installed theme was written for an old version of GTK

Note that also GtKLookAndFeel (as well as the new Nimbus-LnF) would
benefit from an enhanced Java2D-XRender backend as both use
translucent images as well as antialiasing.


3.) Project plan:

The planning as well as the implementation consists of several milestones:

Milestone1: Implement the changes to the GTK theming interfaces
(prototype does exist).
This will be done first because it will take some time until GTK+
maintaines (if at all) will accept the patch and until the new version
of GTK+ and themes have spread on desktops.
The success of the project can't be defined wether the patch is
accepted by the maintainers or not, however I will try hard to
eliminate valid concerns and technical problems.

Milestone2: Implement the Xrender-Java2d backend

Milestone2.1: Ensure performance and quality of the Java2d backend by
extensive testing and profiling.

Milestone3: Implement the changes to GtkLookAndFeel and do extensive
profiling and benchmarking to ensure the performance is on par with
the WindowsLookAndFeel.

Milestone4: Implement JQS for Unix platforms.





4. Results:
The sucess of the projects will be measured by the success in planning
and implementing the features mentioned above.

5. Developer(s):
Clemens Eisserer is Student at the Technical University of Vienna
(Informatics), has submited a few patches to jdk-collaboration and
OpenJDK and sucessfully finished commercial projects about
client-server architectures.