How to make a wide virtual Tree-View Control with only two levels fast? - c++

I basically want to have the same virtual performance I can get with a List-View control. With a List-View control you can set an ItemCount and in the LVN_GETDISPINFO notification you then fill in the information for the items once they are scrolled visible.
Now, the virtual functionality the Tree-View provides is good for very deep trees, so you would only add items once a node expands (via TVN_ITEMEXPANDING), and TVN_GETDISPINFO can be used for filling in item information once the item is scrolled visible. But what to do if you have an "always expanded" two-level tree (just for design matters) where TVN_ITEMEXPANDING wouldn't be of any use and only want to add the items once they would be visible. The problem is, there's no such thing as SetItemCount() or similar to already resize the tree.
In my case, the filling of item information (text, image, selected image) isn't the expensive part, but the inserting of items (all at one level) is.
One option would be to only insert the items which would be visible plus one invisible one, once the invisible one gets visible (detected in TVN_GETDISPINFO), I'd insert a few more and so on. But then the scrollbar would always get smaller the more I scroll down, I think that's weird.
Are there any other ideas to achieve what I want except from drawing my own control?
The whole tree would just look like this, pretty much a list, it's just that I like the tree-look.
RootNode
|
|--Item 1
|--Item 2
|--Item 3
|--Item 4
|--Item 5
|--Item 6
|--Item 7
...
|__Item 1000

As stated in many other posts, the really expensive part about the Tree-View control is using InsertItem and DeleteItem. A quick way to improve performance for those operations is making use of SetRedraw. Not only does it hide the flickering but does really speed things up, since the drawing seems to be expensive - even though TVN_GETDISPINFO is used.
Also, it's faster to rename existing items and change their data instead of deleting and adding new ones. So when I have a big list and know that the next update will contain about the same amount +/- a couple ones, I go iterate through the items, rename them, change their lparams and sync (i.e. remove/add) the remaining ones in accordance to the new data. Depending on the size of the list, making those extra calculations can have a huge performance improvement.

The Win32 TreeView control does not support the kind of virtual mode you are looking for. So you will need a custom control.

Related

QListWidget performance with many custom items

I have a list with about 2500 custom items. I set them with:
const std::vector<const Items::AbstractItem *> results = _engine.request(text);
if (!results.empty())
{
for (auto i : results){
QListWidgetItem *lwi = new QListWidgetItem;
_results->addItem(lwi);
ListItemWidget *w = new ListItemWidget;
w->setName(i->name());
w->setTooltip(i->path());
_results->setItemWidget(lwi, w);
}
_results->setFixedHeight(std::min(5,_results->count()) * 48); // TODO
_results->show();
}
This takes about 5 seconds on an i5-4590. Hiding the widget is twice as fast. Is this normal or do I have look for errors?
A few ideas:
Try assigning proper parents to your QWidgets, thats way the layout doesn't have to do this
mapping for you. This should help performance.
Call setUpdatesEnable(false) before starting the insert, and to true after it's done
As for hiding the widget while adding large amounts of items, this will help to alleviate extraneous update calls. The second suggestion above should mitigate that.
I think this is fully expected behavior for controls like Lists or Trees that are not based on any data model. And I believe that the data model was invented mainly to fix this issue.
In your situation you have a ListWidget control that stores its data on its own. You need to pass all 2500 items before your app can go on, and you need to do this even if your list shows only 10 items at a time. Even if you just run and close your app, the user won't see all the items but you still need to pass them to your ListWidget. Some GUI frameworks use internal allocation of items and in such case they can optimize things a bit, you could do the same if you allocated your Items in chunks but it's still not a good solution.
Now let's say you introduce some object that could be asked about item properties. The Control will ask about some item and your object will respond with the contents. Your object don't even need to know about all your items, it will just learn when needed.
You Control can ask about few first items and stop when it realize it can fill up its entire height. This way you can avoid work that is not needed for now. The Control can also ask about the item count, so it can set-up its vertical slider.
It needs to be said that the model will not solve your problem automatically, it's just a programming paradigm that allows you to do it better.
So the solution for you would be to replace your QListWidget with a QListView and implement you own data model inheriting QAbstractListModel. You could pass the results to the model and it will pass the items data when needed.
If your QListWidgetItem's always has fixed size, call setUniformItemSizes on your QListWidget, pass true.

QTableWidget performance optimization

I have a QTableWidget that can display a huge number of elements (like, 20000 elements). Displaying per se and scrolling up and down works find, however, populating the widget works extremely slowly. I found out that constructing the QVector of elements (strings) that are displayed works very fast, however, inserting the elements into the QTableWidget is very slow.
I need to implement filtration over the elements, so if the user filters half of the elements out with a wildcard, it's still necessary to clean the QTreeWidget and insert 10000 elements back (or hide 10000 elements which is equally slow). Reasonably fast performance is critical here because the user can't wait for several minutes every time he presses a button.
Valgrind doesn't help much as apparently much of the resources are eaten by some implicitly called functions, particularly QHeaderView::sectionSize() and QHeaderView::isSectionHidden()
Migrate Your code to model-view pattern.
Create a model (subclass QStandardItemModel) and place all Your data there.
Display all the data in QTableView, ensure everything is OK
Now, You can use QSortFilterModel model for fast data-filtering, or you can subclass QProxyModel for more complex filters.

wxCheckListBox Filtering function

I'm currently trying to apply a filter to the wxCheckListBox (for a search of specific elements). So far i have no idea how to do it. The Problem with it is, that I don't want to have a copy of the Control and always delete the unnecessary items from the copy, and as soon as the search changes it has to be copied again from the original and delete the items again. I was wondering if there is a way to simply hide some items and not the entire control
You can't hide the items in a wxListBox or wxCheckListBox. To have this sort of dynamic control over the items appearing in the control you need to use wxListCtrl in virtual mode.
However it's not usually really a problem to delete some items from a wxListBox and then insert them back (or, even simpler, store all the items, delete some of them from the control and then, to revert, clear the control and restore all the initially stored items).

Virtual List Controls (MFC)

I am using a List Control to display a representation of elements within a vector. When the list is clicked on another control shows information about that element. The index of the element is currently determined by its index in the control, however if I wish to sort or filter the results this will no longer work.
I have been told that I could use a virtual list control, but the MSDN is not very friendly, can someone run me through how I could use a virtual list control for this?
Frankly - tying data (the position in your data vector) to the presentation of the data in the list control (the position in the list ctrl) is something I would stay away from.
In MFC each control has a "Data" DWORD member variable - when coding in MFC I Always called "SetItemData" for each item added and passed in a pointer that the relevant row referred to e.g.
YourListCtrl.SetItemData((DWORDPTR)&YourData);
Then when the ListCtrl item is selected, you just call
DataTypeYouWant* pData = (DataTypeYouWant*)(YourListCtrl.GetItemData(indexofselecteditem));
Or somesuch thing.
Alternatively - if you don't want to use pointers - hold the index of the item in your original vector in the itemdata for your row (just pass it into the above fns).
To use a virtual list control, set the LVS_OWNERDATA style. You then need to handle the LVN_GETDISPINFO notification message (which is sent via WM_NOTIFY).
If you do this, you are entirely responsible for the data, including the order in which it is shown. Therefore it is up to you to handle sorting and so forth.
By far the easiest way is just to use the item data to set/get an ID that can be used to retrieve the original data, whether that's a vector index or a pointer to the data, or even a key into an associative container.
It really depends on the performance you require.
I have personally seen MAJOR increases in performance for lists holding massive amount of data. However it is much more work to implement, thus for simple uses with not so many data I recommend staying away from it.
Basically, what happens with virtual list controls is that you have your data somewhere in some data structure of your own. Since the list view shows only a small subset of the whole data, it queries you for the content to display when ever something happens (redraw necessary, scroll up or down, change the sorting, etc.).
I don't have handy examples for you. But you can look on codeguru, I am quite sure there are very good examples to start from.
The purpose of virtual list controls is totally different: You should use it for performance reason when you have A LOT of items in your list (I'd say 2500+).
In your case, all you need is to store the vector index in the list item data as NotJarvis explains.

User interface for reordering a list items

I have a list of items as a part of a web application. The question is how user can manipulate the order of items in the list (not the list sort order). The typical way is to use arrow buttons to move items up or down. The other way is the drag-and-drop.
But are there any other ways for a user interface for list reordering?
There are two other sorting methods (besides those you mentioned) I've seen which work pretty well.
Click To Move
The method used for ordering items in the Gallery web photo album works pretty well for ordering photos, and it should work just as well for any set that can be represented as a sorted group of clickable elements:
Present your list of items as clickable elements.
Clicking an element "selects" it, it is highlighted to indicate it's selected.
Clicking another item moves the selected item to a position just before the clicked item.
Repeat until all items are in the desired order.
A dummy item is shown at the end of the list for moving items to the end.
This is slightly easier to use than drag-n-drop as it requires less dexterity, and you don't have to hold down the mouse button while you figure out where you want to "drop" the item.
The method could easily be extended to allow selection of multiple items (via shift-click or similar) which could then be placed in a new position in the same way.
Provide Order Numbers
Used by Netflix and some internal apps I've worked with. This works best if your users have a concrete idea of exactly what the numeric order should be (used when working with lists of instruction steps in our internal app).
Present your list of items one per line.
Provide a text entry box next to each item where the order number is displayed, starting with 1.
The user changes the order numbers in the text fields as desired.
If multiple items are given the same order number, they are placed next to each other.
Provide a button to "apply" the sort in JavaScript so that the user doesn't have to submit the entire page to see the re-arranged list. This makes it easy to work in increments.
Edit: A couple of additional thoughts on Drag-and-Drop. You might have used these before or not, but there are a few things that can make drag-and-drop more forgiving and easier to use:
Highlight the area where the item will appear when dropped. For example, show a prominent horizontal line between the two existing items where the item will be inserted if it is dropped.
Ghost the draggable item as it is dragged so that it's obvious what's being moved, rather than using a generic "dragging" cursor. This works best if the items being dragged are still legible if shown on top of one another with transparency.
Make sure the target areas where the draggable can be dropped are sufficiently large. Larger areas can be helpful for people who have trouble with the required coordination.
We've found that drag and drop can be counter intuitive for non-technical people. We have explored the Up Down Arrow which works but can also be cumbersome as you need to keep clicking up and down and it results in a lot of traffic.
Another paradigm we've explored is the Move button so each item in a list has a Move Item button when you click it new buttons are added before and after each item in the list to let you move the item to any location.
This works well when each item in the list takes a lot of space, if each list item is only a single row it can result in a cluttered interface. In our case each item was half a dozen lines of text or more. We also have add item here button before / after each item to allow insertion.
Survey Monkey uses this paradigm as well and inspired some of what we do.
Some thoughts - Very much on the ideas rather than implementation end though...
1 - Provide both up and down arrows and drag and drop, and monitor which is more popular, which type of users use which etc, then tailor from there once you have some data
2 - Add a "random" button which generates the order randomly - could be useless, could be fun depending on your app
3 - Add a "display order" field by the side of each item and allow the user to manipulate it (but make sure that you have some code to auto update the rest of the numbers when one changes) personally I think this could be very confusing, but for some users it might work
4 - Instead of drag and drop in place, have users drag to a new list
5 - For a very simple version, have a "favourite" check box, and then have the list just show the favourites first, (in alphabetical order or something)
6 - Have groups - you assign a group number to an item, all the group ones appear first, followed by group 2 etc
Hope this random rambling has been useful, if i think of anything more I'll come back...
1) A variation of Click to Move would involve having a separate target list, where the user selects the slot into which their item will move, then clicks on the original item to move it.
For example, in the following diagram, the user has already put 'E' at the head of the reordered list and has selected slot three for their next choice. Their next step would be to choose which item from the old list goes into slot three on the new list. (The row of asterisks is a feeble attempt to show that slot three is highlighted or selected.)
old new
----- -----
| A | | E |
| D | | |
| C | |*****|
| | | |
| B | | |
----- -----
Clicking on an item in the new list selects it and highlights its original slot in the old list, which is now a target. Clicking on the item a second time returns it to that original slot.
The new list should also display indicators of some sort to show that it has selectable regions, perhaps unobtrusive (low-opacity) numbered buttons in its slots or some other informative affordance.
2) Another approach would be to allow users to draw lines between the original and desired positions.
Whatever method is chosen, the process need not be chatty: there's no reason this couldn't all be done client side (with the option to save and commit changes to the server).
You can experiment with drag-and-drop using the examples of jQuery UI Sortables.
To make it obvious for the non-technical or new users you could use visual cues such as handles or arrows and maybe a tooltip on hover to suggest dragging the element.
You could even provide an animated gif demonstrating the gesture.
As soon as a user learns how to do this I think it's the easiest method of ordering a list.
Another way is to provide a small text input next to every item, so the user can enter a numerical ordering themselves; then they click a button to reorder it all at once. (I've only seen this used on sites that store the order of items, such as Netflix queue or Livejournal links.)
Sorting, by clicking on headers is very popular. Perhaps only considered as a reordering of the view of the actual list, though.
Implement a copy/paste style function? This would mean you can take an item out of the list, and then select another item, and click "paste" or CTRL+V. This is quite intuitive and would allow large lists to be manipulated easily.
You could implement multi-selection easily to move a large block of adjacent items.
Network traffic would be low (only one or two requests).
You need to make sure the "paste" is consistent. I.e. pasting always inserts above the selected item.
Take a look at Checkvist for more inspiration.
You could also use arrow keys to move up and down.
I actually think the iphone / itouch does this really well when moving application icons.
If you haven't seen it look here: http://www.youtube.com/watch?v=qnXoGnUU6uI
The 'shaking' icons are a very good visual cue that something is moveable/draggable.
So I would suggest this approach with drag an drop. Clicking and holding on an item could put it in 'moveable-mode' and this would be indicated by it shaking (or some easier to code visual cue). Then drag and drop would work in the normal way.
Implementing this in javascript is of course the challenge...
Also another thing to think about - most people make the mistake of conflating usability with learnability. Think who the users of this app are (will they use it regularly and be taught how to use it, or are they public web users who may use it infrequently and not be taught how to use it) - it might give you a different answer to what the solution should be.
To me, performing a drag and drop of list elements in place (i.e. within the list itself) is the best approach.
Not only you can give to your users the immediate idea of what their list will look like (the list is reorganizing before their eyes), but it's also very easy for them to understand the moving mechanism.
And this is the briefest way to have your users ordering the list in the shortest number of moves.
By the way, foreseeing that a list could be longer than few elements, alongside the DnD method you could provide an asynchronous way to order the list: give the user the ability to attribute an ordering number to each entry, and then click on the "Order" button.
Handling in a smart and correct way user's input, this could result in a speed up for longer lists editing.
I was thinking of "Move selected to here":
Let all items be selectable by checkboxes
Let all items have a button or icon meaning "Move selected to here"
When "Move selected to here" is clicked, all selected items are moved to this item in existing order
The edge-cases here are when the items should be moved to either end of the list. One way to solve that, is to move all selected items before the target, and reserve a special button/icon at the end to move the selection there.
I've found the following to be the quickest way to allow specifying item order regardless of list size:
1) If user wants to set the order of list/grid items, they click a "Reorder" button.
2) This opens the reordering dialog which can be used with any list or grid.
3) In the dialog, all of the items are shown in their current order in a list on the left. There is an empty list on the right.
4) The user clicks the items in the left list in the desired order. When an item is clicked, it is removed from the left list and placed in the right list in the next position. In a worst case reordering where every item needs a new order, this allows ordering a list of N items with N clicks.
5) The user can then apply the new order or cancel. Applying the order results in the "display order" field in the data being set to the final order of the items in the right list. You can decide if the "Apply" button is only enabled when the left list is empty.
6) Also available in the ordering dialog are the following controls:
a) A button to move all of the items from the left list to the right list maintaining whatever order they are in
b) A button to start over by reloading the left list in its original order and clearing the right list.
c) A button to sort the right list alphabetically (or by date or numerically depending on what the key field is)
d) Drag and drop capability in the right list to manually drag items into order.
e) An index number column in the right list which, if edited, moves the item to that position.
This provides the best of all worlds. If you have a huge list where only a few items need to be moved, move all items over, then drag the few items where desired or enter the desired index. If you have a small-ish list that needs to be completely reordered, just click the items in the desired order. And so on.
I've used this approach for many years and it has been very effective.
You can show 'Up' and 'Delete' buttons just the way Google does for SearchWiki. Most of the people have at least some experience with it now. Most people bother only with 'Upping' their choice. If they do not like a thing, and want to downvote it, removing from the list with help of the abovementioned 'Delete' button will be easier for them
You could show an overlay when hovering over an element. This overlay shows you 4 arrows (n/e/s/w) and u can click and move the element accordingly.
If you are trying to oder items across a grid like facebook's and picasaweb's photo grouping features, then that is about the only way to handle that
if you had 3 columns each with a list of items, clicking on any of the items would move the item either to the left or right, middle column could show option for left or right. you could still allow for dragging and dropping or sorting using the typical functionality for that.