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