[sjivan]

I got that link off the GWT project page, specifically:

http://code.google.com/p/smartgwt/wiki/NightlyBuilds_and_MavenRepository

Updated the URL, thanks.

[tomhj]

My application does have filtering capability - but it doesn't stop users from trying to scroll all over the place.

Through wonderful tools like GWT and SmartGWT, we've been able to convert full featured desktop applications to run in a browser. But that hasn't changed the users expectations about what they can do with such a rich interface.

Point well taken about Feature Sponsorship. I'll pass that along.

[Isomorphic]

That is possible, although we've seen a wide variety of database systems and other data stores (relational and non-relational) and performance characteristics seem pretty consistent :)

Another possibility is that you haven't thought hard enough about a good filtering interface, or even an alternative, domain-specific paging mechanism that would be more usable than a scrollbar with this data volume, and faster.

Regardless, if you think it's worthwhile to build in scrollbar support for paging through this size of dataset, consider Feature Sponsorship.

[tomhj]

You are making (invalid) assumptions about my backend and whether my users are willing to wait 10 seconds to see their data.

And yes, my app does also support filtering - but it doesn't stop them from trying to scroll all over the place.

[Isomorphic]

Right, that makes sense if you ignore the part about it being terrible for server performance and less useful than filtering interfaces.

[tomhj]

Positioning within the data via dragging the "thumb" will always be approximate. No one will expect pin point accuracy to scroll down to row 1,245,345 out of 1,500,000 for instance.

But most users do expect to be able to scroll 1/2 or 3/4 down with the thumb and get to roughly 1/2 or 3/4 of the data set. If it's +/- 1,000 rows because one scrolling pix equals 1,000 rows within a huge dataset - that is fine.

[Isomorphic]

With progressive scrolling you can pick however far you want to allow the user to jump scroll, so by advertising a dataset length of eg 10k records, you can show a minimum size thumb and allow limited jump scrolling into the beginning of the dataset.

Beyond that size, the scrollbar and thumb cannot represent the relative page and dataset size (because this require a sub-pixel thumb) so show it externally if it's important.

[tomhj]

True, the user can reverse the sort. But the relative position of the scroll "thumb" is not reflecting the reality of the dataset - and that is a usability problem IMHO. And even if the user does continue scrolling down, the totalCount will continue to increase and eventually the ListGrid will break.

I think I can live with things the way they are now - just putting in my $.02 that the completely virtualized scrolling system would be ideal.

[Isomorphic]

So again, free-scrolling through this many rows doesn't make sense from either a usability or database performance perspective. To hop to the end, the user can reverse sort; for anything else, using a filtering interface makes much more sense than a scrolling interaction in which each pixel moved corresponds to more than 1000 rows traversed.

[tomhj]

thanks Sanjiv.

I downloaded the build from last night. Using the progressive scrolling when the row count is over say 500,000 seems to work but makes it virtually impossible for the user to scroll all the way to the last row (they would have to scroll down past the 'end' 1,000,000/75 or 13,333 times).

The completely virtualized paging system sounds like what is really needed.

[tomhj]

I got that link off the GWT project page, specifically:

http://code.google.com/p/smartgwt/wiki/NightlyBuilds_and_MavenRepository

[sjivan]

I tried grabbing the latest nightly from http://www.smartclient.com/smartgwt/builds/

but the 'latest' directory has a timestamp from Monday at 8pm - no nightly build Tuesday night with the change?

Where did you get that URL for the builds? It is no longer current and should not be used. The right place to look for nightly builds is : http://www.smartclient.com/builds/

Sanjiv

[tomhj]

I tried grabbing the latest nightly from http://www.smartclient.com/smartgwt/builds/

but the 'latest' directory has a timestamp from Monday at 8pm - no nightly build Tuesday night with the change?

[Isomorphic]

We found a new, native browser bug in IE8 where it would not respect the size of very large spacers, and found and checked in a workaround that allows us to extend the scrollable area to enough pixels to accommodate somewhere above 500k rows. It's available in the current nightly build.

Because this has happened before with other browsers, we may in the future implement a completely virtualized scrolling system so we're not relying on the browser to respect large content sizes.

However for now, above about 500k rows, use the progressive scrolling approach described in ResultSet. It's better for the server, and free-scrolling through that many rows is useless for an end user anyway (consider, each scrollbar pixel in a 500px tall grid represents 1000 rows).

[tomhj]

Any word on this?

Also note that in the sample app, the row count threshold when the problem starts is much higher - ~10,000 in my real app but in the sample, it doesn't go completely haywire until scrolling to about 90,000 row.