[news.eclipse.platform.swt] Re: [performance] When is updateElement call

[<cpuidle@xxxxxx>]

> Even more interesting- when using the mouse to scroll to the end of the 
> table and back, suddenly the strange keyboard behaviour is solved- no more 
> call to updateElement are observed then.

Please disregard this part- due to bug.

Checking the stack trace of keyboard navigation calls to updateElement, I 
see that the getVirtualSelection method is responsible for callig 
udpateElement

Thread [main] (Suspended (breakpoint at line 105 in 
ContactsView$ContactsContentProvider))
 ContactsView$ContactsContentProvider.updateElement(int) line: 105
 TableViewer(AbstractTableViewer).getVirtualSelection() line: 497
 TableViewer(AbstractTableViewer).getSelectionFromWidget() line: 468
 TableViewer(StructuredViewer).getSelection() line: 972
 ColumnViewerEditorActivationStrategy.isEditorActivationEvent(ColumnViewerEditorActivationEvent)line: 47 TableViewerEditor(ColumnViewerEditor).handleEditorActivationEvent(ColumnViewerEditorActivationEvent) line: 436 TableViewer(ColumnViewer).triggerEditorActivationEvent(ColumnViewerEditorActivationEvent) line: 680 TableViewer(ColumnViewer).handleMouseDown(MouseEvent) line: 664I guess this is the root problem- getVirtualSelection _always_ callsudpateElement withour checking if it's already associated with element datalike e.g. AbstractTableViewer's addTableListener is doing:Object element = resolveElement(index);if (element == null) { // Didn't find it so make a request // Keep looking if it is not in the cache. IContentProvider contentProvider = getContentProvider(); // If we are building lazily then request lookup now if (contentProvider instanceof ILazyContentProvider) {  ((ILazyContentProvider) contentProvider)    .updateElement(index);  return; }}