View Issue Details

IDProjectCategoryView StatusLast Update
0027475LazarusLCLpublic2015-03-23 17:39
Reportertheo Assigned ToZeljan Rikalo  
Status closedResolutionfixed 
Product Version1.3 (SVN) 
Summary0027475: ListView.OnData called too often on Linux in mode OwnerData.
DescriptionGTK2 calls OnData for _every_ Item initially, even if not visible.
I think a "virtual" view should not do this.

Qt calls OnData only for the visible Items, but never stops.
It calls OnData over and over again, which might use quite a lot of CPU time, depending on what you do in this event.

Win32 works as expected.

For a test project, please see:

The attached file contains the output (for gtk2, qt, win32) of the following changed method of the test project:

procedure TfrmMain.ListView1Data(Sender: TObject; Item: TListItem);
  Item.Caption := SList[Item.Index];
  Writeln(item.index,' : ',TimeToStr(now));
TagsNo tags attached.
Fixed in Revision47804
Attached Files



2015-02-15 12:02

reporter (1,897 bytes)


2015-02-15 12:09

reporter   ~0081094

I forgot to say: The output in is done without scrolling or MouseOver events and the like. Just clicked "Add Items" and then moved the cursor away.

Zeljan Rikalo

2015-02-15 15:47

developer   ~0081102

Qt is fixed with r47804. Please test.


2015-02-15 16:14

reporter   ~0081107

Great thank you. It is still calling OnData more than once for each visible item, but it stops then.
I think this is OK.

Zeljan Rikalo

2015-02-15 16:48

developer   ~0081108

Yes, because paint event is triggered twice: 1st time when OnData is called, and second time after you change Item in OnData. This is how it works under qt.
I'm afraid that I cannot fix gtk2 in this case. It always calls all items for the first time.

Zeljan Rikalo

2015-02-15 17:46

developer   ~0081111

Qt is fixed, gtk2 is impossible to fix.


2015-02-15 17:55

reporter   ~0081112

Can't we hack around it on Gtk2?
I mean we know that it is calling all items and then the visible items again.
In my code, I can solve it like this:

procedure TfrmMain.Button1Click(Sender: TObject);
  GtkLVInit := True;
  ListView1.Items.Count := 100;

procedure TfrmMain.ListView1Data(Sender: TObject; Item: TListItem);
  if ((Item.Index = ListView1.Items.Count - 1) and GtkLVInit) then
    GtkLVInit := False;
  if GtkLVInit then
//from here on I have the desired behaviour

I have no idea where to put this in GTK2WS Code.
I think it would be nice to have this working.

Zeljan Rikalo

2015-02-15 20:29

developer   ~0081114

Only thing which comes to my mind is place where we send LM_PAINT from gtk2.


2015-02-16 13:44

reporter   ~0081134

I think I have a solution now.
Please see the attached patch.

The GTK2 Items initially do not have a DisplayRect (top and bottom are 0)
So the useless calls all come from such items with "no dimensions".
This only happens on GTK2, as far as tested. So this patch changes nothing for
Win or Qt. It think it is quite safe.


2015-02-16 13:45


listitem.diff (556 bytes)   
Index: lcl/include/
--- lcl/include/	(Revision 47808)
+++ lcl/include/	(Arbeitskopie)
@@ -835,9 +835,14 @@
 procedure TOwnerDataListItem.DoCacheItem;
+var Dr:TRect;
-  FCached := True;
-  FOwner.FOwner.DoGetOwnerData(Self);
+  Dr:=DisplayRect(drBounds);
+  if not ((Dr.Top=0) and (Dr.Bottom=0)) then
+  begin
+   FCached := True;
+   FOwner.FOwner.DoGetOwnerData(Self);
+  end;
 function TOwnerDataListItem.IsOwnerData: Boolean;
listitem.diff (556 bytes)   

Juha Manninen

2015-02-16 15:39

developer   ~0081137

Theo, better reopen the issue when you have new patches.

Zeljan Rikalo

2015-02-16 19:40

developer   ~0081141

I don't like that patch. Root of problem is somewhere else.

Zeljan Rikalo

2015-03-16 15:04

developer   ~0082010

@theo, just tested with your patch and it doesn't do anything since I've fixed returning rects from items. Initial call of all items by gtk2 is not fixable by me, so proposal is to resolve if you agree.


2015-03-18 18:22

reporter   ~0082085

Yes please close.
Thank you.

Zeljan Rikalo

2015-03-18 18:57

developer   ~0082088

Please close.

Issue History

Date Modified Username Field Change
2015-02-15 12:02 theo New Issue
2015-02-15 12:02 theo File Added:
2015-02-15 12:09 theo Note Added: 0081094
2015-02-15 15:47 Zeljan Rikalo LazTarget => -
2015-02-15 15:47 Zeljan Rikalo Note Added: 0081102
2015-02-15 15:47 Zeljan Rikalo Status new => feedback
2015-02-15 16:14 theo Note Added: 0081107
2015-02-15 16:14 theo Status feedback => new
2015-02-15 16:48 Zeljan Rikalo Note Added: 0081108
2015-02-15 16:48 Zeljan Rikalo Assigned To => Zeljan Rikalo
2015-02-15 16:48 Zeljan Rikalo Status new => assigned
2015-02-15 17:46 Zeljan Rikalo Fixed in Revision => 47804
2015-02-15 17:46 Zeljan Rikalo Note Added: 0081111
2015-02-15 17:46 Zeljan Rikalo Status assigned => resolved
2015-02-15 17:46 Zeljan Rikalo Resolution open => fixed
2015-02-15 17:55 theo Note Added: 0081112
2015-02-15 20:29 Zeljan Rikalo Note Added: 0081114
2015-02-16 13:44 theo Note Added: 0081134
2015-02-16 13:45 theo File Added: listitem.diff
2015-02-16 15:39 Juha Manninen Note Added: 0081137
2015-02-16 15:39 Juha Manninen Status resolved => assigned
2015-02-16 15:39 Juha Manninen Resolution fixed => reopened
2015-02-16 19:40 Zeljan Rikalo Note Added: 0081141
2015-03-16 15:04 Zeljan Rikalo Note Added: 0082010
2015-03-16 15:04 Zeljan Rikalo Status assigned => feedback
2015-03-18 18:22 theo Note Added: 0082085
2015-03-18 18:22 theo Status feedback => assigned
2015-03-18 18:57 Zeljan Rikalo Note Added: 0082088
2015-03-18 18:57 Zeljan Rikalo Status assigned => resolved
2015-03-18 18:57 Zeljan Rikalo Resolution reopened => fixed
2015-03-23 17:39 theo Status resolved => closed