What is the parameter value represents in "setDrawAheadRatio(2.0)” for list grid ?

[vnathank]

Hi Isomorphic,

Thank you for your support.

We faced an issue with our list grid, where two empty records (with only checkbox) are displayed at the end when scroll bar is dragged down.

Explanation:
1. In my listgrid pagination support is added(30 records will be loaded each time).
2. When the list grid contains 32 records and if i scroll down the scroll bar last two records values are displayed as empty.
3. But when i set "setDrawAheadRatio(0.9f)” property on listgrid it is working fine.

But we want to know more information about "setDrawAheadRatio(0.9f)” property and especially value(Ex: "0.9f" represents what information).

Note: Sample screen shot is attached for your reference.

Thank in advance.

Smart GWT Version: 6.1 pro
Google chrome version: Version 65.0.3325.162 (Official Build) (64-bit).

Note:
We are using SmartGWT 12 Pro also.
In some sample code, we observed that setDrawAheadRatio(2.0) is used.

[Isomorphic]

This is a bit of an odd post.. drawAheadRatio is a documented property, so simply read the docs.

Then, as far as this issue, you’ve provided is no way for us to reproduce it. Obviously it doesn’t happen in samples.

[vnathank]

Hi Isomorphic,

Thank you for your reply.

As we are not getting the definition clearly, We would like to confirm our understanding.
Our understanding w.r.t. Smartgwt documentation "setDrawAheadRatio()" property is, it will behave as below.

1. For "setDrawAheadRatio(2)" it will load two additional rows more than the view-able records.
2.For "setDrawAheadRatio(4)" it will add four additional rows more than the view-able records.

Please let us know whether our understanding is correct.

[Blama]

Hi vnathank,

as I understand it, it's a percentage of the viewport, e.g. if the ListGrid with its current height is displaying 10 rows, setDrawAheadRatio(3) will pre-render 20 additional rows, so that scrolling is smooth. Therefore a value <1 does not make sense and will most likely cause some kind of problem.

Best regards
Blama

[vnathank]

Dear Blama,

Thank you so much for your response.

1. We faced this issue when screen resolution is "1920 * 1080" or "1600 * 900".
2. Actually in our case, we are not using SmartGWT in server side(Only client side). We are using struts framework on server side for request and response.
3. When setDrawAheadRatio() propertyparameter value is 1 or more, based on the screen resolution, this is adding 30 are more rows.
4. Our server module( not Smartgwt server) always returning 30 records only (Pagination).
5. In this case UI (SmartGWT ListGrid) is drawing more than 30 rows with checkboxes(in our requirement one of the column(field) contains "checkbox") , however as there is no data available, those extra rows are displayed without any data.
6. if we use "setDrawAheadRatio(0.9f)", all data is displayed properly with all resolution combinations.

Please let us know if you have any thoughts. Thank you.

Regards,
vivek

[Blama]

Hi vnathank,

sorry, really not my expertise. But I'm pretty sure that Isomorphic will tell you that your server has to answer as expected w.r.t. to the request's startRow and endRow and also that those numbers must be correct in the response.
Setting setDataPageSize(30) might be a good start, if your server is always returning batches of 30. But I'm not sure if this is enough.
If the client requests row 40-70 and you only return 30-60 or similar, this might be a problem (if this is the case).
Also I don't know what happens when dataPageSize is less than needed for drawAheadRatio, like it is the case for you.

setDrawAheadRatio(0.9f) sounds strange to me. What happens if you use setDrawAheadRatio(1.0f)?
And can't you make your server return batches of more than 30 (e.g. 50), so that this is enough for a big screen and default drawAheadRatio?

Best regards
Blama

[Isomorphic]

Blama is correct - you can't simply have your server ignore the requested row range. That will produce exactly the results you're seeing, which are not a bug.

Any drawAheadRatio setting less than 1 is also obviously invalid, as this would cause less rows to be rendered than are currently visible in the viewport, which will look broken.

[vnathank]

Dear Isomorphic,

Thank you for your response.

As our server side implementation is using other (struts) framework, we are trying to fix this issue using the ListGrid.getViewportHeight API as described below.

1. setCellHeight(30); \\ default height of each row is set to 30 pixels.
2. int totalRecordSize = (ListGrid.getViewportHeight()/30) + 1; //Ensure that server provides data for enough records (Equal to or one more than the number of rows drawn in the UI)

\\ as per the smartgwt API doc, getViewportHeight() Returns the height of the viewport onto the scrollable content.

1. So in each request(pagination support case), it gets “totalRecordSize” number of records and display in the list grid.

Please let us know whether "ListGrid.getViewportHeight" will provide\return correct height of viewport or not, Thank you.

[Isomorphic]

That would be incorrect, because the "body" AutoChild is the actual scrolling region, but calling getViewportHeight() on the body would work.

However, your whole approach here appears to be wrong. The request sent to the server by the grid already contains the requested rowNums, so there is no need to calculate them yourself. If you are hoping to arrange sizing on the grid so that it just happens to request row ranges your current server logic is able to return, that approach will ultimately fail, because there are many, many circumstances in which the grid will request row ranges that don't happen to fall on multiples of the viewport; one example is that the user scrolls 1/2 page and does something to invalidate the current cache.

Furthermore it is a critical feature of any modern UI that a component like a grid appears larger and shows more rows if the browser is larger, and/or if the user chooses to hide other components to give the grid more room. So attempting to constrain the row ranges that the ListGrid will request would just cripple your UI (if it were even workable, which it is not).

Instead of spending more time on this investigation, you should be refactoring your server code so that it can return arbitrary row ranges.