JDK-6177888 : Java2D still a bottleneck when used over remote X11
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-10-12
  • Updated: 2010-04-02
  • Resolved: 2005-06-03
Related Reports
Duplicate :  
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