TListView issues (linux ?)

[dbannon]

Hi folks, looking for a second opinion.
TListView is a really useful component. However, its giving me some problems and I am surprised they are not mentioned in either the bug tracker or the forum. So, I wonder if I am doing something wrong ?

I use TListView in OwnerData mode and some end users of my app will have 20K entries in their TListView. I recently added the Multiselect mode and find it triggers a Memory Leak. There is an attached project demonstrating this leak (and several other issues). You can choose to build in GTK2 GTK3, QT5 or Qt6 mode.

To test, choose gtk2, Qt5 or Qt6, compile and run the project as supplied, click to select one of the entries in the ListView and then close it all down. You will see a Heaptrc report.

I believe the leak originates in  line #891 of WSComCtrls.pp in the class procedure TWSCustomListView.Upda]"]>BlockedltiSelList(const ALV: TCustomListView; AItem: TListItem; Add: Boolean);

in this line "FMultiSelList := TIntegerList.Create;"     

However, there seems to be other issues I noted while putting the demo together.

Firstly, gtk2 makes a call to every data point in its range instead of just the visible ones (as OwnerData should). See the number bottom left of the demo screen. Ah, interesting, that as a bug report already, I logged it in 2022, https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39803

Second, gtk2, Qt5 and Qt6 makes extra calls for data, unnecessarily, during mouseover events. No new data lines are exposed, why ask for more data ?

Third, GTK3 does not work at all in OwnerData mode, I need to log that.

Finally, if you give up on using OwnerData, better make sure you don't put too many lines into the TListView. Qt5 maxes out at around 500, on the other hand, Qt6 can handle 50,000 ! Big difference. There is a {$define OwnerData} if you want to pay with the demo in non-OwnerData mode.

I think that there are several bug reports here, or am I doing something silly ?

Note : I am currently traveling and don't have Windows or Mac hardware with me.

Davo

[Thaddy]

That is quite normal. Use TVirtualListview for views with much data. (The leak is a different story, but your component choice is wrong if the data is large. It will also be SLOW)

[wp]

I can confirm your observation with the memory leak in non-Windows widgetsets. It is fixed when I free the FMultiSelList in the TCustomListView destructor:

Code: Pascal  [Select][+][-]

1. destructor TCustomListView.Destroy;
2. var
3.   lvil: TListViewImageList;
4. begin
5.   Application.RemoveAsyncCalls(Self);
6.   // Better destroy the wincontrol (=widget) first. So wo don't have to delete
7.   // all items/columns and we won't get notifications for each.
8.   FreeAndNil(FCanvas);
9.   inherited Destroy;
10.   FreeAndNil(FMultiSelList);
11.   FreeAndNil(FColumns);
12.   for lvil := Low(TListViewImageList) to High(TListViewImageList) do
13.     FreeAndNil(FImageChangeLinks[lvil]);
14.   FreeAndNil(FOwnerDataItem);
15.   FreeAndNil(FListItems);
16.   FreeAndNil(FIconOptions);
17. end;

Not 100% sure whether this is the correct place. The FMultiSelList is created by the widget class, TWSCustomListView. So I would say that this is also the class which is responsible to destroy it. But that has only class methods and thus has no access to the FMultiSelList (for creation the TCustomListView is passed as a parameter to the class method). On the other hand, FMultiSelList is a member of TCustomListView (kind of strange construction...), so that I think that it should not be harmful when TCustomListview destroys it.

The mouse-over calls to OnGetData, in my opinion, are caused by the possibility of hot-tracking which triggers a repaint of the exited and entered nodes, and for this, the virtual data of the entered node at least must be retrieved.

I cannot comment on the gtk3 and qt5/qt6 behaviours that you report. Maybe file a bug report so that Zeljan can have a look.

[jamie]

I run that code on my Windows 10 I5-64 bit in 64bit mode app, I get "0 ms" for ownerdata mode.

Is just about instant!

Jamei

[dbannon]

I can confirm your observation with the memory leak in non-Windows widgetsets. It is fixed when I free the FMultiSelList in the TCustomListView destructor:

OK, I looked at doing that and it worked but I really did not understand the relationships happening here so chickened out.

So, you found this 'fix' is not necessary under Windows ? That surprises me, I understood this is common code. If that is the case then how does Windows release that memory ?   Maybe I had better wait until I get home and test under Windows and Mac before putting in a bug report ?

The mouse-over calls to OnGetData, in my opinion, are caused by the possibility of hot-tracking which triggers a repaint of the exited and entered nodes, and for this, the virtual data of the entered node at least must be retrieved.

Yeah, I guess that might make sense. In my case, it seems to make little of no impact on performance.

I cannot comment on the gtk3 and qt5/qt6 behaviours that you report. Maybe file a bug report so that Zeljan can have a look.

Yes, Zeljan has asked for a bug report about GTK3, I am still working on it. The Qt5 problem is just slow, maybe thats just how it is ? Both Qt5 and Qt6 works perfectly (and very fast) in OwnerData mode (with your fix).

Once again, WP, thanks !

Davo

[jamie]

I have no leaks with Laz 4.2 - 3.2.2 on windows

[dbannon]

Is just about instant!

Yes Jamie, OwnerData mode is blinding fast because its not dealing with data the user cannot see. Very sensible !

Did you look for that memory leak, you need to click on at least one data line in the ListView and then exit ?

OK, that confirms suspicion, "I don't understand the situation". I'll chase this u when I get home, mid August. Thanks !

Davo

[jamie]

yes, I selected a bunch or items.

On windows I just hold the  Shift key down and just Click away to select ..

I will note that on windows I believe this to be a native control and that part of it may be handled by the OS instead of locally, which would meen the fMultiSelList just does not get used ?

Jamie

[wp]

I can confirm your observation with the memory leak in non-Windows widgetsets. It is fixed when I free the FMultiSelList in the TCustomListView destructor:

OK, I looked at doing that and it worked but I really did not understand the relationships happening here so chickened out.

So, you found this 'fix' is not necessary under Windows ? That surprises me, I understood this is common code. If that is the case then how does Windows release that memory ?   Maybe I had better wait until I get home and test under Windows and Mac before putting in a bug report ?

The MultiSelList is used in the general widget code only (unit WSComCtrls). In Windows, the related widget methods are overridden because multi-selection is handled by the OS directly and thus there is no need for the MultiSelList (see also comment in lcl/interfaces/win32/win32wscustomlistview.inc) which therefore is never created there, remains at nil and thus causes no harm when calling FreeAndNil in the TCustomListView destructor.

[dbannon]

Hmm, I have also found that getting a list of the selected items is quite slow if you have a large dataset behind it. And that is because, if SelCount is greater than 1, you need to either scan over all listview1.items or get the control to do so, same thing.

But it happens that the control knows internally which ones are selected, that is the list discussed further up. So, I would consider patching ~.TWSCustomListView.GetNextItem() to recognise its only being asked about "selected" and quickly returning an answer based on contents of FMultiSelList. Much cleaner would be a new call, eg, TWSCustomListView.GetSelectedList() to directly expose FMultiSelList or make the list public ...

Anyway, that is a separate issue to the memory leak.  Unless you want to act on it immediately WP, I plan to wait until I am home, mid-August where I can test, carefully on Windows (Jamie has already) and Mac. Your call.

Davo

[dbannon]

Hmm, I have also found that getting a list of the selected items is quite slow if you have a large dataset behind it. And that is because, if SelCount is greater than 1, you need to either scan over all listview1.items or get the control to do so, same thing.

Bug report and fix posted. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41798
Affects Linux and MacOS, not windows. Huge speed up for huge data sets !

Anyway, that is a separate issue to the memory leak.  Unless you want to act on it immediately WP, I plan to wait until I am home, mid-August where I can test, carefully on Windows (Jamie has already) and Mac. Your call.

Bug report and fix posted. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41796
Affects Linux and MacOS only.

Davo