> Should be fixed now in r22947
> Btw I set the count to 100 and it loaded almost instantly, so no
> huge delay at startup.
> Regards,
> Andrew.
I just checked out rev 23015 and I'm not getting the crash any more
when clicking on the list view item.
There is not a delay at startup for me e
Seth Grover wrote:
>> Okay In r22945 I have implemented a custom treemodel for the gtk2
>> listview. This should fix your memory problem.
>>
>> Regards,
>>
>> Andrew
>>
>
> I tried your update. Yes, the memory usage is somewhat better now
> (before it was something like 100MB with 1 million items
>
> Okay In r22945 I have implemented a custom treemodel for the gtk2
> listview. This should fix your memory problem.
>
> Regards,
>
> Andrew
>
I tried your update. Yes, the memory usage is somewhat better now
(before it was something like 100MB with 1 million items in the list,
now it's around 4
Seth Grover wrote:
> Basically I created a form and dropped a TListView onto it and set the
> OwnerData property to True, then defined an OnData event like:
>
> procedure TForm1.ListView1Data(Sender: TObject; Item: TListItem);
> begin
> Item.Caption := 'Item ' + IntToStr(Item.Index + 1);
> end;
Paul Ishenin wrote:
Andrew Haines wrote:
I did a small test loading a text file with 50,000+ lines with my custom
model and the GtkTreeView retrieved the value of each item in the list
on startup. I assume it's to calculate the size for the scrollbar since
the height of the listitems is not fix
On Wednesday 02 December 2009 04:53, Paul Ishenin wrote:
> Andrew Haines wrote:
> > I did a small test loading a text file with 50,000+ lines with my custom
> > model and the GtkTreeView retrieved the value of each item in the list
> > on startup. I assume it's to calculate the size for the scrollb
Andrew Haines wrote:
I did a small test loading a text file with 50,000+ lines with my custom
model and the GtkTreeView retrieved the value of each item in the list
on startup. I assume it's to calculate the size for the scrollbar since
the height of the listitems is not fixed but can vary per r
Andrew Haines wrote:
> I did a small test loading a text file with 50,000+ lines with my custom
> model and the GtkTreeView retrieved the value of each item in the list
> on startup. I assume it's to calculate the size for the scrollbar since
> the height of the listitems is not fixed but can vary
Paul Ishenin wrote:
>>
> ListViews on gtk can't be absolutely virtual - they need to have all the
> items. But captions, checks, etc are not stored in it (in the case of
> virtual) - they are requested before the drawing. So you should have
> some memory reduction in comparition with the real li
> ListViews on gtk can't be absolutely virtual - they need to have all the
> items. But captions, checks, etc are not stored in it (in the case of
> virtual) - they are requested before the drawing. So you should have
> some memory reduction in comparition with the real listview.
>
> Only windows h
Seth Grover wrote:
However, for the purposes of testing, I then increased the count to
100, since a major purpose of a virtual list view is so you don't
have to eat up all your memory storing the items.
To my dismay, when I ran the program, it ran correctly, but the memory
usage of my progra
Hello all (and especially Paul Ishenin since it's your fix I'm referring to),
http://bugs.freepascal.org/view.php?id=7749
This was recently marked as fixed for gtk2 in the Lazarus trunk. I
pulled from svn this morning and built everything and put together a
quick test program.
Basically I create
12 matches
Mail list logo
