Hi,
Lainaus Federico Mena Quintero [EMAIL PROTECTED]:
El jue, 29-03-2007 a las 17:43 +0300, [EMAIL PROTECTED] escribió:
Using arrays in GtkTreeDataSortHeader doesn't appear to be optimal,
because their length is not constant. We would end up to
alloc/dealloc/copy sequence when adding
El jue, 29-03-2007 a las 17:43 +0300, [EMAIL PROTECTED] escribió:
Using arrays in GtkTreeDataSortHeader doesn't appear to be optimal,
because their length is not constant. We would end up to
alloc/dealloc/copy sequence when adding new items.
From a quick look at the code, the only place
Hi,
On Mon, 2007-03-26 at 19:06 -0600, Federico Mena Quintero wrote:
I was looking at the GtkTreeView code and it looks like there are other
places that could get the array treatment. One place in particular was
the sorting machinery... GtkListStore also uses a GList of information
for the
What hadn't ever been made clear is if real-world applications were
seeing performance problems caused by the dashed stroking. It sounds
like maybe you're on to one of those now.
To be fair, even though it's a justifiable use, that's an extreme
case - with the font I'm using, one tree row is
Nicolas, can you get another profile using Markku's patch?
Most certainly!
A couple of preliminary remarks.
I have observed a startup time increase of between 20% and 30%.
When scrolling, here is what I observed:
- when displaying the selected row, performance is as bad as
before
2007/3/27, Nicolas Setton [EMAIL PROTECTED]:
Nicolas, can you get another profile using Markku's patch?
Most certainly!
A couple of preliminary remarks.
I have observed a startup time increase of between 20% and 30%.
When scrolling, here is what I observed:
- when displaying the
On Tue, 27 Mar 2007 17:50:08 +0200, Nicolas Setton wrote:
Interesting, the dashed stroke is exactly what's causing problems -
thanks for the pointer!
Ah, ...
though I *think* it has been adressed since. But if you are running
1.4, that would hint that it still is a problem.
There have
El lun, 26-03-2007 a las 00:18 +0300, [EMAIL PROTECTED] escribió:
I tried this idea and changed the GtkTreeDataList to be an array instead of
linked list (see the attached patch, made against svn head). The original
testcase (5000x50 model) started up faster (but was still slow), but I didn't
Hi,
Lainaus Federico Mena Quintero [EMAIL PROTECTED]:
Exactly. GtkListStore is implemented as a GSequence (a splay tree),
where each node is one row in the list. Then, the data for the row's
columns is stored in a linked list (GtkTreeDataList). You could
reimplement GtkTreeDataList in
On Thu, Mar 22, 2007 at 08:18:14PM +0200, Tommi Komulainen wrote:
On 3/22/07, Kalle Vahlman [EMAIL PROTECTED] wrote:
2007/3/22, Yevgen Muntyan [EMAIL PROTECTED]:
IIRC reusing single cell renderer in multiple columns was declared
broken and unsupported (because it was broken). Is this
2007/3/23, Kristian Rietveld [EMAIL PROTECTED]:
On Thu, Mar 22, 2007 at 08:18:14PM +0200, Tommi Komulainen wrote:
On 3/22/07, Kalle Vahlman [EMAIL PROTECTED] wrote:
2007/3/22, Yevgen Muntyan [EMAIL PROTECTED]:
IIRC reusing single cell renderer in multiple columns was declared
El jue, 22-03-2007 a las 16:55 +0100, Nicolas Setton escribió:
Hi, Nicolas,
Thanks for taking the time to profile this!
Consider the subprogram attached. It shows a simple tree_view
displaying a list_store (5000 columns and 50 rows containing
integers). The display performance is very
El vie, 23-03-2007 a las 23:19 +0100, Michael Natterer escribió:
I would rather say we absolutely don't abuse lists here. There is no
significant difference between list and array for a couple of items
(say 50 items). The only abuse I see is creating a treeview with
5000 columns. The widget
On Fri, 2007-03-23 at 17:35 -0600, Federico Mena Quintero wrote:
El vie, 23-03-2007 a las 23:19 +0100, Michael Natterer escribió:
[...]
What GTK+ needs here is a *sheet* widget, something that is optimized
for organizing two-dimensional data in an efficient way. Hacking up
GtkTreeView for
This describes an idea to improve the display performance of the
tree_views, based on the sources of gtk+-2.10.11, and suggests
possible solutions.
Consider the subprogram attached. It shows a simple tree_view
displaying a list_store (5000 columns and 50 rows containing
integers). The
2007/3/22, Nicolas Setton [EMAIL PROTECTED]:
[snip]
So, it seems that we spend most of our time traversing the list of
columns. Note that this explains why a tree of 5000 columns x 50 rows
has such bad performance compared to a tree of 50 columns x 5000 rows.
Your test program is also creating
On Thu, Mar 22, 2007 at 04:55:30PM +0100, Nicolas Setton wrote:
Consider the subprogram attached. It shows a simple tree_view
displaying a list_store (5000 columns and 50 rows containing
integers). The display performance is very poor: when displaying the
last columns, the vertical
Kalle Vahlman wrote:
2007/3/22, Nicolas Setton [EMAIL PROTECTED]:
[snip]
In any case, I suggest we cache this - probably there is no need to
do it in every expose call, only after the model data has changed.
...so it isn't really feasible to cache the renderer state. The good
news
2007/3/22, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
2007/3/22, Nicolas Setton [EMAIL PROTECTED]:
[snip]
In any case, I suggest we cache this - probably there is no need to
do it in every expose call, only after the model data has changed.
...so it isn't really
On 3/22/07, Kalle Vahlman [EMAIL PROTECTED] wrote:
2007/3/22, Yevgen Muntyan [EMAIL PROTECTED]:
IIRC reusing single cell renderer in multiple columns was declared
broken and unsupported (because it was broken). Is this correct?
It worked amazingly well for being broken ;)
Maybe there
[Thanks everyone for your answers]
There is a really simple answer to this: GtkTreeView is not a table,
it was not designed to handle views like this with 50 columns.
I'm not sure I understand this part: should I use a gtk_table to
display this kind of data? What is the preferred way to
21 matches
Mail list logo
