-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 7
-
Component/s: client-libs
-
x86
-
linux
There is significant performance difference between application with a number of Swing JTable cells when running in a standalone JFrame or in (J)Applet. After some investigation, the root cause was found:
BasicTableUI.paintCell->CellRendererPane.paintComponent->Container.validate->Component.updateCursorImmediatly->GlobalCursorManager.updateCursorImmediatly()->_updateCursor....
updateCursorImmediately() takes about 20% of EDT calls which is pretty inefficient. However, when running inside an applet, it takes up to 50% of the time because of the next call:
XEmbeddedFramePeer.getLocationOnScreen()->XBaseWindow.toGlobal()->XEmbeddedFramePeer.getAbsoluteX/Y()->XlibUtil.translateCoordinates()
BasicTableUI.paintCell->CellRendererPane.paintComponent->Container.validate->Component.updateCursorImmediatly->GlobalCursorManager.updateCursorImmediatly()->_updateCursor....
updateCursorImmediately() takes about 20% of EDT calls which is pretty inefficient. However, when running inside an applet, it takes up to 50% of the time because of the next call:
XEmbeddedFramePeer.getLocationOnScreen()->XBaseWindow.toGlobal()->XEmbeddedFramePeer.getAbsoluteX/Y()->XlibUtil.translateCoordinates()