12.0p ListGrid drawAheadRatio only applied at initial ListGrid draw, 2.0 otherwise

[Blama]

Hi Isomorphic,

creating this thread I noticed that the drawAheadRatio is only applied at start IMHO.
Please see this modified online testcase (v12.0p_2019-08-15) with drawAheadRatio: 1.10 and drawAheadRatio: 5.00 and enable gridHTML Debug logging in the Developer Console.
For me, the sample in "Tahoe spacious" displays 20 rows at start.

isc.ListGrid.create({
    ID:"dsListGrid",
    width: "30%",
    height: 680,
    autoFetchData: true,
    dataSource: "supplyItem",
    dataFetchMode: "local",
    showSelectedRollOverCanvas: false,
    sortField: "itemID",
    //drawAheadRatio: 5.00,
    drawAheadRatio: 1.10,

  fields:[
       {name: "itemID", width: 60 },
       {name: "itemName"},
       {name: "SKU", hidden: true},
       {name: "category", hidden: true},
       {name: "unitCost", hidden: true},
       {name: "units", hidden: true},
       {name: "inStock", hidden: true},
       {name: "nextShipment", hidden: true},
       {name: "description", hidden: true },
    ]
});

These are the log statements when you start the sample and mouse-wheel scroll very slow until the next log entry.

drawAheadRatio: 1.10:

14:50:15.268:TMR6:DEBUG:gridHTML:dsListGrid_body:getTableHTML:  columns 0->1, rows 0->21, time: 3ms (44 cells at 0.07ms per cell, 14666.67 cells per second), spacerHeights: [0,125984], left/right pad: [0,0], 0 single cell rows
14:50:18.179:TMR3:DEBUG:gridHTML:dsListGrid_body:getTableHTML:  columns 0->1, rows 3->41, time: 2ms (78 cells at 0.03ms per cell, 39000.00 cells per second), spacerHeights: [96,125344], left/right pad: [0,0], 0 single cell rows

IMHO it should be rows 3->24 here in the 2nd row to have the same difference as 0->21.
(3->41 is 39 rows, the same you would get at start for drawAheadRatio: 2.00)

drawAheadRatio: 5.00:

14:51:51.026:TMR0:DEBUG:gridHTML:dsListGrid_body:getTableHTML:  columns 0->1, rows 0->95, time: 9ms (192 cells at 0.05ms per cell, 21333.33 cells per second), spacerHeights: [0,123616], left/right pad: [0,0], 0 single cell rows
14:52:22.327:TMR1:DEBUG:gridHTML:dsListGrid_body:getTableHTML:  columns 0->1, rows 76->114, time: 3ms (78 cells at 0.04ms per cell, 26000.00 cells per second), spacerHeights: [2432,123008], left/right pad: [0,0], 0 single cell rows

IMHO it should be rows 76->171 here in the 2nd row to have the same difference as 0->95.
(76->114 is 39 rows, the same you would get at start for drawAheadRatio: 2.00)

I can see though that the specified drawAheadRatio is used when doing a "drag-scroll fast-release" or clicking the empty scrollbar area above or below the handle to scroll by exactly one page.
It seems that this number is not applied when scrolling slowly. Here it is always 2 * viewport rows.

I'm investigating this as I want to get rid of the white area shown when scrolling. If this is noticeable or not depends of course on the ListGrid's complexity and one could perhaps win something here by not using recordComponents.
Aside of this, it seems that with drawAheadRatio I should be able to trade the time the white area is shown (better with low drawAheadRatio) against count the white area is shown (better with high drawAheadRatio). But this is not true as you can see above.


Another improvement suggestion would be to also have a "drawBehindRatio" (or to use some amount of the drawAhead for drawBehind), so that it is not possible to trigger getTableHTML() for mouse-wheel up.
This might feel a bit constructed, but happens always if you drag-scroll and then scroll up.

Best regards
Blama

[Isomorphic]

There are multiple heuristics at play here based on the different types of scrolling.

The default heuristics we apply already work well for you and are unrelated to the problem you're trying to solve. If you raised drawAheadRatio you would just lengthen the delay (because more rows would be rendered at once) and if you lowered it, you would cause more frequent redraws, so more frequent opportunities for visible delay.

We have already explained the best way to eliminate the brief delay you are seeing with certain types of scrolling - eliminate your usage of recordComponents in favor of the better approaches we document.

You should go with that approach rather than a further investigation of drawAheadRatio, which is currently just wasting time.

[Blama]

Hi Isomorphic,

agreed. recordComponents usage is the low hanging fruit here.

Thank you & Best regards
Blama