Notes on Speed Improvements on Rendering

note: for further info see the emails with subject _OJ extreme slowness_ on Jump User List around 28/29 November 2006 A big thanx to Larry and Bob for investing the time! sstein

• Larry Becker wrote* (30 Nov. 2006):

OK, let's see if we can't put this issue to rest. The RenderingManager has a 1 second repaint timer that allows the GUI to appear responsive by updating the screen every second during long operations like dataset loading. The code is:

<code>

private Timer repaintTimer = new Timer(1000, new ActionListener() {
        public void actionPerformed(ActionEvent e) {
            for (Iterator i = contentIDToRendererMap.values().iterator(); i
                    .hasNext();) {
                Renderer renderer = (Renderer) i.next();
                if (renderer.isRendering()) {
                    repaintPanel();
                    return;
                }
            }

            repaintTimer.stop();
            repaintPanel();
        }
    });
</code>

Notice the final repaintPanel() invocation. This is what is triggering the second paint that Fco is seeing. I have commented out the final repaintPanel() and observed no ill effects on correct rendering, however it had no positive effects on render times either. I recommend leaving it as is for belt-AND-suspenders paranoia.

Robert and I have done fairly extensive analysis of JUMP's rendering pipeline and have not found anything that can be significantly improved. We have done experiments with blocking vs. non-blocking renderers and found no improvement. Robert tried rendering more features in each synchronized draw invocation (as Jon's comment recommended) and found no improvement in speed. I want to emphasize that all of these mods have decreased the responsiveness of the GUI without noticeably increasing drawing speed.

In conclusion, the results of our benchmarks, analysis, and experiments show that JUMP's rendering is one of the best compromises of quality, responsiveness, and speed that I have ever seen in an application.

One final word: late tests of JUMP 1.2 of redraw of the 48MB burlulc.shp file (New Jersey) dataset have deteriorated to 20 seconds from 11 in the previous version. I an unaware of any reason for this slowdown, except for perhaps the addition of the new Imaging layer type since OpenJUMP and SkyJUMP have implemented most of the JUMP 1.2 improvements except Imaging and do not experience any slowdown.

regards, Larry Becker ISA