Description Scott Ellsworth 2003-09-03 16:20:52 EDT

Bug 42196 dealt with underlying JDT performance.  According to that bug, now closed, the issue 
has been resolved for the general JDT case.  Since this still lags on a Ti/667 with 3.0M4, it seems 
likely that the remaining speed issues are SWT issues.

3.0M4 feels faster than previous versions at this task, but it still brings up the Spinning Wait 
Cursor on a Ti/667.  I believe that sub-second response times are a reasonable target for a 
machine of this class, at least in the long term.

The java gaming initiative has made JOGL a front runner for code development.  Because this is a 
direct port of OpenGL, the GL class has a great number of methods and static final constants in it.  
These cause the method popup in the editor to show up very, very slowly.

import net.java.games.jogl.*;
import net.java.games.jogl.util.*;

public class Test
{
    public void display(GLDrawable gLDrawable)
    {
      final GL gl = gLDrawable.getGL();
      gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
    }
 }

Start typing a duplicate of the second line of display into the function.  On my TiBook 667 with 
10.2.6 running Eclipse 3.0M3, I see the following:

Typing gl. pegs the cpu for 17 seconds when typed the first time, 9, 8, 9, 7, 8, and 9 seconds for 
later invocations.  (Timing by eye, so these all seem to be about 8 seconds.)

Typing GL. pegs the cpu for 5 seconds reliably.  There does not seem to be a cache effect going 
on.

A build of JOGL for MacOS X 10.2 can be found at <http://homepage.mac.com/fuz>.  This tgz file 
contains the needed jar file to reproduce the problem.