I have tested the new background folder size implementation (with cm_CountDirContent) and observed the following behavior on parent folders containing many large (20GB) sub-folders. XP SP3.
1. Folder tree behavior
During the calculation, the file panel opposite the calc is "live" and very responsive to navigation (:)).
But, upon the first navigation (in that opposite file panel), its folder tree blanks out and does not repopulate until the large folder completes and TC moves on to the next folder.
When the long size calculation completes and the empty folder tree refreshes, it sequentially flickers through the tree state of each navigation before settling on the final one that matches the file panel location.
I conclude that updates to the folder tree are queued and pushed to the display only at the conclusion of the large folder enumeration (ie., when it moves to the next "parent" folder).
2. TC window update
During the very long folder calc mentioned above, switching away from TC (using alt-tab, for instance) routinely displays the next open application. But sometimes switching back to TC does not redisplay the TC window until the folder calculation completes.
Also in some circumstances it is not possible to use alt-tab to switch to TC after the entire folder calc completes.
For instance, currently I have two instances of TC running on the desktop. The second one (where the folder calculation appears to have concluded) is inaccessible from alt-tab and does not appear when directly accessed from the task bar.
1. Both the tree and the size calculation use background threads, both with the same thread priority (lower than the main window). What would you suggest?
2. Cannot reproduce - do you get this only with separate trees enabled?
1. Several ideas come to mind, not sure what would work best, or is feasible. The purpose of all of them is to avoid the unfriendly and unhelpful "empty" tree panel.
- Since navigation in the opposite file panel updates smoothly and is very responsive during the enumeration, this suggests to me that the issue may be in the tree update routine itself. If the tree is already drawn, then TC knows which node corresponds to its file panel. If the file panel updates successfully (after navigation) this means that TC knows what node SHOULD be current in the tree (to match the file panel). It also knows whether that node is "available" in the tree. Perhaps there is no need to go back out to the file system to refresh the tree if the user's navigation remains within a specific domain (such as a disk volume) that the tree has already accessed (i.e. "knows about")? A navigation up an already expanded branch of tree could reset the active node and a issue high priority repaint.
If the user navigates "outside" of the known tree (such as to a previously un-accessed network share), then repaint the tree showing the new active node, but post text (such as "Pending") to the node name (or its domain parent, if necessary), such text to be replaced as soon as possible.
...or...
- The first time TC services a UI interaction in the "opposite" panel, lower the priority of the folder enumeration thread. After an interval where no UI interaction is detected, raise it back up.
...or...
- Do a task resources assessment before starting a massive enumeration, and build a schema of subtotal threads that are triggered sequentially. The termination of a subtotal thread could free the tree update thread. Due to the overhead of such an approach, let the user set a preference flag in the INI: [x] Favor background threads where appropriate.
...or...
- When starting the enumeration thread, temporarily stop en-queuing tree updates that occur in response to navigation within the opposite file panel. Post a message to the "empty" tree ("Please wait" or "Busy" or something) and wait until a message is received from the enumeration thread. When the message from the enumeration thread is received, inspect the current location of the file panel, then issue a single tree update. This would suppress the intermediate tree updates I have observed at the end of the large folder calc.
2. Sorry not to have tried other modes yet. I exclusively use dual tree.
I have checked it now - the tree is actually updated in the same thread as Alt+Shift+Enter. I will consider to put these functions in two separate threads.
