United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6177888 : Java2D still a bottleneck when used over remote X11

Details
Type:
Enhancement
Submit Date:
2004-10-12
Status:
Closed
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2005-06-03
Component:
client-libs
OS:
solaris_9
Sub-Component:
2d
CPU:
sparc
Priority:
P3
Resolution:
Duplicate
Affected Versions:
1.4.2
Fixed Versions:

Related Reports
Duplicate:

Sub Tasks

Description
A DESCRIPTION OF THE REQUEST :

When a Jav2D application (including anything written using Swing/JFC) is deployed on a Unix or Linux system to a non-local X11 display, the application tends to be slowed down and often blocked as the Java2D and AWT subsystems handle the display.

This doesn't occur when a local X11 display with the MIT-SHM extension is used.

Typically, the blocking occurs when Java2D has finished performing a compositing operation locally and needs to ship the resulting bitmap over the wire. No consideration seems to be given in the compositor to queued drawing requests within the application, even when those requests might ultimately produce display updates which write-over earlier changes.  Ideally, the compositor might be in a position to optimise it's queue better and 'throw away' or combine otherwise redundant requests.

JUSTIFICATION :
Currently, Swing applications still cannot be deployed to X11 servers such as workstations, Sunray servers or Tarantella with the same performance as when they are deployed on a Windows Terminal Server or Citrix Metaframe server. In those cases, the remote display engine is capable of 'throwing away' redundant data and the Swing application is rendering to local shared memory.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
 Ideally, the compositor might be in a position to optimise it's queue better and 'throw away' or combine otherwise redundant requests.

---------- BEGIN SOURCE ----------
Run the Java2D demo on a local X11 workstation versus a remote server versus a Windows Terminal server, and note that the application takes signficantly longer to run from start to end in the remote X11 case.
---------- END SOURCE ----------
###@###.### 10/12/04 20:21 GMT

                                    

Comments
EVALUATION

In our experience (and many of our customers), since the introduction 
of acceleration of offscreen images via pixmaps in 1.4, typical 
swing applications perform quite well when running remotely.

With the new XAWT toolkit  added in 1.5 by the awt team, this is even more so
as XAWT eliminates a considerable overhead associated with Motif too, 
something which helped a lot for cases with high latency connection.

By 'typical swing application' I mean applications which do not go beyong 
of what X11 protocol can handle  - no antialiased rendering, alpha compositing.

Some themes for Gnome Look and Feel, however, do use translucency and 
compositing a lot, so this would be a scenario where a swing application
would not perform adequately when displayed remotely.

If the customer has a sample application which performs poorly
when displayed remotely, it'd be great to have it attached to the
bug report so we can investigate.

Also, please specify the metrics under which swing application performance
for the remote-displaying is considered acceptable.
These metrics should probably depend on the network latency.
###@###.### 10/13/04 18:16 GMT

No information from the submitter. Closing the bug as a duplicate
of a generic "Some Java2D operations over remote X11 is slow"

###@###.### 2005-06-03 14:39:12 GMT
                                     
2004-10-13



Hardware and Software, Engineered to Work Together