ListGrid and Edit by Row - slow navigation with TAB key

[hschack]

I have a ListGrid with editing by row. While editing a row, I experience some slowness when navigating with the "TAB" key from one cell to the next cell of the line.

So far I found out the following:
The slowness seems to be related to overriding ListGrid.createRecordComponent().
For some reason the navigation with the TAB key becomes slower depending on the number of records available in the datasource.

In order to isolate the root cause I have build a minimal example with a ListGrid and a simple ImgButton in one of the columns.
It is derived from the standard example com.smartgwt.sample.BuiltInDS.

I have attached two stack traces of IE profiling. In both samples I navigated three times between edited cells by pressing the TAB key.
* In "tabKeyNavigation_With_Embedded_Components.PNG" we see that changing the edited cell triggers isc_Gridbody_redraw, which seems to be rather costly.
* For the second stacktrace "tabKeyNavigation_Without_Embedded_Components.PNG" I have removed the overridden createRecordComponent() method. In this case TAB-key navigation works fast. The stack trace shows that isc_Gridbody_redraw is not triggered.

I'm wondering whether the call to isc_Gridbody_redraw is really required in the first case?

I'm using SmartGWT Framework (v9.0p_2013-09-17/PowerEdition Deployment) and IE 9. Source code of the minmal sample is attached below.

[hschack]

I would conjecture that the performance of isc_Gridbody_redraw can be improved for a ListGrid with embedded component. This should be possible at least in the case where the embedded component has always the same fixed height than the rows of the grid.

Any comments on this?

[Isomorphic]

We've made a change to address this issue - please retest with a nightly build dated November 28 or later

[hschack]

Thanks for following that up. I tested with the nightly build of Nov-28. Indeed the slowness issue of the TAB-navigation is resolved when navigating between cells in a row.

There is still the slowness when navigating from the last cell of a row to the first cell of the next row by pressing TAB.

I also see the following warning message in the log, each time the TAB key is pressed:

16:11:41.239:MDN5:WARN:ListGrid:isc_BuiltInDS_1_0:refreshRecordComponent() called with no colNum. This parameter is required when showRecordComponentsByCell is true. Taking no action.

    at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:105)
    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:293)
    at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547)
    at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
    at java.lang.Thread.run(Thread.java:722)

[Isomorphic]

We've made a further change to remove that warning - however, note that this change, and the previous one, were only made in 4.1.

Earlier in this thread, you mentioned that you were using "v9.0p_2013-09-17", which is a 4.0 build.

Can you confirm which version you're actually using?

[hschack]

I did the previous test with the Nov-28 nightly build of 4.1.
I will retest with the latest 4.1 build.

[hschack]

I tested with the 4.1 nightly build of Dec 3.

There is no warning message any more.

The remaining issue is the slow navigation with TAB from the last cell of a row to the first cell of the next row. This is still disturbing for the user.

You can replicate it with the minimal sample attached previously.

[hschack]

Any update on the remaining issue? The fix for it is probably quite similar to what was already done before for the tab navigation within a row.

[hschack]

Hello Isomorphic,
Do you plan to fix the remaining issue in the near future? Otherwise I would have to look for a workaround. Thanks for your feedback.

[Isomorphic]

We don't consider this (a redraw when the editRow changes) to be a bug, with a necessary fix - that said, we'll look at whether an improvement can be made - no ETA