<Swing Dev> Inefficiencies with custom TableCellRenderer and Applets

Clemens Eisserer linuxhippy at gmail.com
Sat May 3 15:00:44 UTC 2008


Hi,

I've created a library which has to use custom TableCellRenderers for
its tables.
I experienced a large performance difference between running my
application as Application inside an JFrame and as an JApplet.
Parented inside of the JFrame scrolling the table was smooth, however
scrolling inside the applet was slow, especially if the mouse is over
the table while scrolling.

I did some profiling with netbeans-profiler and found the root-cause:
BasicTableUI.paintCell->CellRendererPane.paintComponent->Container.validate->Component.updateCursorImmediatly->GlobalCursorManager.updateCursorImmediatly()->_updateCursor....

The updateCursorImmediatly was called both times about 16.000 times,
with JFrame it consumed 22% of the cycles which is already
inefficient.
As JApplet it calls into getLocationOnScreen() which calls down till
XBaseWindow.toOtherWindow even slower which is about as slow as
updating the Cursor itself, so as applet it consumes 48% of all EDT
cycles.

The DefaultTableCellRenderer simply overrides validate with an empty
method, therefor no such calls are done.
But why does CellRendererPane.paintComponent() call validate at all?
If it cannot be avoided, is there no way to cache stuff in
XBaseWindow.toOtherWindow at all?

Thanks, lg Clemens













Very simple TableCellRenderer which triggers the slowness:
	  JLabel renderer = new JLabel();
	  public Component getTableCellRendererComponent(JTable table, Object value,
	      boolean isSelected, boolean hasFocus, int row, int column) {
		 renderer.setText((String)value);
		 renderer.setOpaque(true);
	    return renderer;
	  }



More information about the swing-dev mailing list