Slashdot Mirror

← Back to Stories (view on slashdot.org)

Sun to Amp Java for Desktop Performance?

Posted by chrisd on from the slow-sometimes dept.

mactari writes "Java client application developers should take a look at Sun's J2SE Client Developer Survey. Swing's relative slowness has always made a Java app with a GUI look and feel slow, and Sun might finally be doing something about it. Questions on the survey suggest Sun is considering moving away from a crossplatform look and feel (eg, Metal) towards native looks by default. If Sun is going to follow the suit played by IBM's native widget toolkit, SWT, or do things on individual platforms like Apple has done with its hardware accelerated version of Aqua-Swing, Java might finally find its way to becoming a competitor on the desktop."

4 of 88 comments (clear)

  1. SWING kicks AWT's ass! by zenyu · · Score: 4, Interesting


    I'm so annoyed by this "SWING is slow" canard. As a graphics programmer I can tell you aside from a few glitches in a few select JVM's SWING is much faster. Only poor programmers who try to implement their whole program in the event handler ever have a problem with SWING. Their programs would suck in AWT too, they would simply freeze with the OS redrawing the buttons. With all the work Sun has put into making threads drop dead easy to use there is absolutely no excuse. They have a hook for running things in a thread from a managed pool, and even a utility for running things in the Swing thread when you're done...

    1. Re:SWING kicks AWT's ass! by bay43270 · · Score: 4, Insightful

      If your going to be condescending, at least be correct. Swings components are not thread safe, true. That does not mean that all code needs to be implemented in the event thread! If fact, that is a classic rookie mistake (as the grandfather post points out).

      Read this interview with the Sun employees maintaining Swing:
      http://developer.java.sun.com/developer/co mmunity/ chat/JavaLive/2003/jl0121.html

      Here's an interesting quote:
      "I think the single biggest difference between so-so and really great Swing apps has to do with the way developers handle threading issues. As everyone knows, Swing is "single threaded," and this often leads developers to avoid using multiple threads. However, this is a BIG MISTAKE. The fact is that you can use many threads in your Swing app; you just need to follow the rules."

      The REAL problem with Swing is that the simplest way to implement any solution is usually also the wrong way. Too many people use DefaultTable model rather than building their own. Too many people subclass components because they 'don't get' UI Delegates. Too many people out there think that since Swing isn't thread safe (and they don't really understand threads enough to know what that means), they should let all their code run from the event thread. Swing's greatest weakness: bad programmers.

  2. Bindings are possible by jaaron · · Score: 4, Informative

    Bindings are possible. For example:

    Java-gnome Just check out google for others.

    --
    Who said Freedom was Fair?
  3. Performance of Java Graphics by jdfekete · · Score: 4, Interesting

    I have been working quite a lot on trying to improve Java graphics performance, starting from Agile2D [http://www.cs.umd.edu/hcil/agile2d/], a free implementation of Java Graphics2D based on OpenGL made by Jon Meyer for the Human-Computer Interaction Lab of the University of Maryland.

    The fact is, using a recent accelerated graphics card (Quadro4 500 GoGL on a Laptop Dell M50), I have speedups of 10 to 200 times compared to the native Java implementation ON THE SAME PLATFORM. These numbers improve on desktops with GeForce 4 or ATI equivalents.

    I am currently improving Agile2D and it is getting better at fonts and most other things as well.
    However, Agile2D cannot completely replace Java graphics right now because the repaint management of Swing is not designed to be modified, leading to refresh problems that I haven't been able to fix so far.

    This means that -- as Apple already realized -- Java graphics can be made much faster in a portable way by relying on OpenGL.

    Of course, on older graphics platforms, OpenGL is slower than software rendering. But using the "Object Technology", it should be possible to engineer two different implementations of Graphics2D and choose the right one at startup time, especially in Java.

    So there is hope for large speedups if Sun switches to hardware rendering or redesign a little bit the Swing RepaintManager to allow external developers to implement the speedups by themselves.