JDK-4204845 : Remote use of double buffering on JDK 1.2 is very slow
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.0,1.2.1,1.2.2_005,1.3.0
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,solaris_2.5.1,solaris_2.6 generic,linux,solaris_2.5.1,solaris_2.6
  • CPU: generic,x86,sparc
  • Submitted: 1999-01-21
  • Updated: 2013-11-01
  • Resolved: 2001-03-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 betaFixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description

Name: dbT83986			Date: 01/21/99


I am leading the development of a new project.  This project 
has receintly bought 10 new Sun Ultra 10s running Solaris 2.6.  
We are developing an application and really hoped to develop it 
in Java using Swing.  The java version we have installed is :
Solaris VM (build Solaris_JDK_1.2_01_dev05_fcsK, native threads, sunwjit)

We have created a very simple test application and find it 
doesn't perform well if we our not running on our local 
machine.  For example: I am sitting at my local machine 
(call it X) and telnet (or rlogin) to a remote machine 
(call it Y).  I type 'xhost + Y' on X and type 'setenv DISPLAY 
X:0.0' in my telnet window to Y.  When I run my Java 
application that has a couple of buttons all implemented 
in SWING, it doesn't run well.  The window takes several 
seconds to come up, resizing the window takes several seconds, 
nothing is very responsive.  Here is the application code:

import java.awt.*;
import javax.swing.*;

public class TestFrame extends JFrame {
  public TestFrame() {
    setSize(500,500);
    setBackground(Color.green);
    try {
      UIManager.setLookAndFeel("Metal");
    }
    catch(Exception e) {
    }
    JPanel topPanel = new JPanel();
    topPanel.setLayout(new GridLayout(3, 2));
    getContentPane().add(topPanel);
    topPanel.setBackground(Color.red);
    topPanel.add(new JButton("Yippee"), BorderLayout.NORTH);
    topPanel.add(new JButton("Skippy"), BorderLayout.EAST);
    topPanel.add(new JButton("YaHoo"), BorderLayout.SOUTH);
    topPanel.add(new JButton("Wow"), BorderLayout.WEST);
    topPanel.add(new JButton("Big Deal"), BorderLayout.CENTER);
  }
  public static void main(String args[]) {
    TestFrame mainFrame = new TestFrame();
    mainFrame.setVisible(true);
  }
}

I have searched the JDC, the Bug Parade, and the FAQs and have 
not found any references to this problem.  Could you please 
tell me if this is a currently limitation of using light weight 
components, or if there is a patch or workaround that I am not 
aware of?  If there is not a fix to this problem, how important 
is it to the Java Team to fix this performance issue?
(Review ID: 53030)
======================================================================

SAP can't upgrade their SAP Java GUI from JDK 1.1.8 to 1.2.2_05a or JDK 1.3
(checked Solaris b16) since customers with X11 remote display technolgy will not
be able to use it anymore.

stefan.schneider@eng 2000-05-26

The proposed workaround is not acceptable for SAP.
Their product uses components from third parties which use the baox layout.
A fix is needed

stefan.schneider@eng 2000-09-22

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta
14-06-2004

WORK AROUND From: Steve Wilson <###@###.###> I found that with a few relatively minor tweaks you can work around this issue in some cases. I've been working with one large customer on this issue (with mostly positive results so far). Here is what you need to try the work-around: 1. J2SE 1.3 (that has some Java2D and Swing fixes that are required) 2. Turn off double buffering in Swing. That means you need to add this line of code to your app (before you create any Swing components): RepaintManager.currentManager(null).setDoubleBufferingEnabled(false); 3. Also, if you're using JScrollPane, you need to make the following addition after you create any scrollpane: scroller.getViewport().setScrollMode(JViewport.SIMPLE_SCROLL_MODE); This combination won't get performance quite as good as 1.1, but it's a heck of a lot better than 1.2 or 1.2.2. FYI, you'll probably want to put a switch in the code that only doesn't these tweaks if you tell the app it is going to run remotely. These tweaks will hurt performance in the local case.
11-06-2004

PUBLIC COMMENTS osy.ujuagu@EBay 2001-10-22 This problem was also observed in SANsurfer (Switch Management tool). Running the application with JDK 1.4 seems to resolve the reported problem.
22-10-2001

EVALUATION This has to do with the way Java2D handles images. In the case described it will render the image on the server and then pipe the bits across. This is expensive. What you'd like it to do is pipe the drawing commands across, instead of the whole raw image. We're currently looking into ways to do this. steve.wilson@eng 1999-01-22 In JDK 1.2 we store the images on the JavaVM side of the connection whereas they were stored on the Xserver side of the connection in JDK 1.1. As Steve mentioned, the drawing commands for most applications take much less bandwidth to transmit to the Xserver than the resulting image so generated. We will need to develop better tools to better balance the tradeoff between storing the pixels remotely in the server where the rendering is much more restricted but the blitting is much faster and storing them on the local side where we have much more control and flexibility for the rendering, but where copying the pixels to the remote display is much slower. jim.graham@Eng 1999-09-28 As of 1.4 we will have a new Image type - the VolatileImage. This new image type was created primarily to enable us to use win32 DDraw images stored in VRAM which are not guaranteed to be stable. But, the relaxation of the guarantees of image accessibility inherent in this new image type also allows us to store the pixels for this new type of image inside the X11 server for the remote case. Thus, applications using a VolatileImage as their double buffer will see a very large speed increase in 1.4. Swing is being modified to use the VolatileImage facility to allocate its double buffers, and so Swing applications will run much faster over remote X11 connections in 1.4. Legacy applications which use createImage(w,h) to create their double buffer images, though, will not see any of this benefit. We are looking into ways to leverage the work done for the VolatileImage implementation to provide similar benefits for remote use of createImage(w,h) images, but such work is still speculative with no specific release targetted. Until then legacy applications using createImage(w,h) for double buffering will continue to experience 1.3 performance levels unless they are rewritten to use the createVolatileImage method (available in 1.4) instead. jim.graham@Eng 2000-11-14 For the remote X11 display case we have enabled the regular offscreen images (i.e. created via createImage(w,h)) to use the new pixmap surfaces that we created for the VolatileImage case. This has led to tremendous speedups for applications using this legacy double buffering interface. Here are the results of some of the benchmarks I ran between 1.3 and 1.4. Note that none of these tests are using any of the 2D rendering extensions such as antialiasing or translucent colors. One of them fills a GeneralPath but only with a solid color so it isn't any more complex than filling a 1.1-based Polygon object except for the presence of curves in the outline data. Customers expecting decent Antialiasing and Alpha performance over the network will not see any improvement until the X11 protocol and implementations are extended to provide similar functionality. Benchmark 1 ----------- Intended to model simple rendering (i.e. 1.1 applications) to a back buffer and blitting it to the screen. Note that even though a GeneralPath is a 2D feature, rendering it in solid non-AA mode boils down to an operation similar to a Polygon fill. Running BezierAnim with only the following options enabled: Clear Background, Render Offscreen, Show Offscreen, Fill And specifically the following options disabled (they would bypass the X11 rendering pipelines): No Antialias, No Alpha Fill Color (Note: BezierAnim is a standalone, configurable version of the BezierAnim pane of the Java2Demo.) The results were: 1.3 < 3 fps 1.4 > 600 fps For a 200x speedup. Benchmark 2 ----------- Intended to measure simple blits of offscreen images to the screen. Running DrawIMGPerf with options "offscr noscale ntests=3". (Note: DrawIMGPerf is a configurable blit engine that can test the performance of blitting various kinds of source images to various kinds of destinations). The results were: 1.3 237369 20x20 <Off-Screen> image pixels per second 268788 100x100 <Off-Screen> image pixels per second 251731 300x300 <Off-Screen> image pixels per second 1.4 4738230 20x20 <Off-Screen> image pixels per second 52882105 100x100 <Off-Screen> image pixels per second 94842452 300x300 <Off-Screen> image pixels per second For a speedup of 20x, 197x, or 377x depending on the size of the offscreen image. Since we have addressed both the Swing double buffering performance and the performance of legacy (1.1-based) double buffering apps I will be marking this bug fixed in Merlin-beta. jim.graham@Eng 2001-03-20
20-03-2001