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

[<cpuidle@xxxxxx>]

Interesting... spending 30min of debugging, I've found that the problem 
_only_ appears when list navigation happens via keyboard instead of mouse.

Using mouse:     updateElement is only called once per table row
Using keyboard:    updateElement is called for each element navigated too- 
also when elements are revisited

To summarize- using keyboard navigation, apparently the TableRow doesn't 
become associated with the element data.

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.

Any idea what that is??

<cpuidle@xxxxxx> wrote in message news:g45vci$9kc$1@xxxxxxxxxxxxxxxxxxxx
> I've developed a virtual table viewer that uses an ILazyContentProvider to 
> retrieve the table items (in this case address book contacts) from a 
> database.
> To fetch batches of contacts from the database using SQlite, the 
> updateElement method looks as follows:
>
> public void updateElement(int index)
> {
> int start = (index / PAGE_SIZE) * PAGE_SIZE;
> System.out.println("Fetching index " + start + " for query " + index);
>
> DatabaseManager dm = AddressBookPlugin.getDefault().getDatabaseManager();
> dm.setLimit(start, PAGE_SIZE);
> ArrayList<ArrayList<String>> data = dm.getData();
>
> int end = Math.max(data.size(), PAGE_SIZE);
>
> for (int i = 0; i < end; i++)
>  viewer.replace(data.get(i), start + i);
> }
>
> However, performance is still poor, and looking at the console I'm seing 
> this when scrolling in the viewer:
>
> Fetching index 0 for query 0
> Fetching index 0 for query 0
> Fetching index 0 for query 0
> Fetching index 2048 for query 2338
> Fetching index 2048 for query 2338
> Fetching index 2048 for query 2338
> Fetching index 4096 for query 4676
> Fetching index 4096 for query 4676
> Fetching index 4096 for query 4676
>
> Apparently, updateElement is called three times with the same index when 
> scrolling (an in turn hits the DB in my case). This seems strange as the 
> methods doc says:
> "Called when a previously-blank item becomes visible in the TableViewer". 
> I was assuming that a previously-blank item is no longer blank after 
> updating once.
>
> I assume this could be caused by the implementation of the viewer's 
> refresh method:
>
> public void replace(Object element, int index) {
> if (checkBusy())
>  return;
> Item item = doGetItem(index);
> refreshItem(item, element);
> }
>
> If the checkBusy() is the problem- then what could be a cure??
>
> Thanks,
> Andi
>