Question

I am implementing virtual scrolling on a grid. The scrolling/on-demand loading feature is working quite smoothly. However, when it’s detected that the user is scrolling quickly (defined as longer than 450ms) a semi-transparent div with a loading gif is displayed while the processing takes place.

My issue is that after the loading is done and the appending is finished, I make a call to hide the overlay expecting to see the updated grid. Instead, I have a 2-3 second delay then the overlay hides and the data shows.

The Question:

Part A: Why doesn’t the div still stay on screen even though the line of code to hide it comes after the appending … causing the unexpected 2-3 second wait with no progress/loading indicator to the user?

Part B: What can be done to ensure the overlay stays visible until the adding to the dom is complete and rendered?

the line of execution looks like this:

    CheckToFetch(id, $(gridScrollElm).scrollTop(), true);
    ToggleOverlay(gridScrollElm, false);

As you can see hear, the overlay ideally should hide after the data is loaded and rendered.

There is a chain of method calls going on behind CheckToFetch but I’ll just show the most relevant piece where appending occurs.

AppendData: function (id, data, firstTime)
{
    var gd = SGrid.GetGridData(id);
    var rowClass = (gd["RecordCount"] + 1) % 2; //sets us on correct course for adding AlternatingRow classes

    var grid = $('#' + id)
    var tbody = grid.children('tbody');

    var rowsToAdd = data["Records"];
    for (var r = 0; r < rowsToAdd.length; r++)
    {
        var elmsQueue = new Array(); //used to do efficient string concat, especially for IE
        elmsQueue.push('<tr>');
        for (var c = 0; c < gd['Columns'].length; c++)
        {
            elmsQueue.push('<td align="');
            elmsQueue.push(gd['Columns'][c]['DataAlign']);
            elmsQueue.push('" ');

            var id = rowsToAdd[r]["id"];
            var cell = rowsToAdd[r]["cell"];

            if (rowClass % 2 == 0)
            {
                elmsQueue.push('class="AlternatingRow">');
            }
            else
            {
                elmsQueue.push('>');
            }
            elmsQueue.push(cell[c]);
            elmsQueue.push('</td>');
        }
        elmsQueue.push('</tr>');
        tbody.append(elmsQueue.join(''));
        rowClass++;
    }

Answer 1

As to part A of your question, I can only assume, that repaint operation (process of actually showing result of javascript operations) can run independently from DOM operations and javascript execution. In your code, you append multiple elements to the DOM, the dom is updated, the reflow is issued to the browser, but that (reflow operation) doesn’t put javascript execution on hold. So if the reflow lasts a bit long, you end up in next javascript function being executed even though you don’t see the result of previous statement yet.

There are couple of resources refering to paint events and dom operations performance: http://www.html5rocks.com/en/tutorials/speed/html5/ (check the Optimization Strategies part), and from one-and-only Paul Irish: http://paulirish.com/2011/viewing-chromes-paint-cycle/

As to part B of your question. If my assumption from part A is right, the only thing you can do is make sure that repaint operations are limited to absolute minimum. In order to achive that, you should put on hold appending the elements until your full set is ready.
In other words, keep collecting the new <tr> elements in an array (or a string), and only then do tbody.append(). To put it simple: move DOM manipulation out of loops.

Defering actual DOM modifications It’s a common practice, and its recommended way of working with scripts that modify the DOM heavily.

To get the every bit of performance, you could also try passing actual objects (created using document.createElement) to the append function, instead of strings, that (obviously) have to be parsed in order to get list of the elements you want to put in the DOM.