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 wh
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 ro
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
> What's your Cairo version?
My tests were done with the 1.4.2 release.
> The input focus rectangle has been
> identified as a performance problem some time ago:
>
> http://lists.freedesktop.org/archives/cairo/2006-October/008135.html
> "Another thing we identified at GUADEC is that the dashed st
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 dis
> 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 (scro
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'
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
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
> > GtkTreeVi
On 3/23/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> * 5000 columns is definitely abusing the *user*. Who cares about the
> toolkit.
Federico,
where you think of "foo", someone else will want to write
"Supercalifragilisticexpialidocious".
You seem to be making a two-step conclusion:
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 wid
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
On Thu, Mar 22, 2007 at 07:44:57PM +0100, Nicolas Setton wrote:
> 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 display this
> kind of information (5000 columns x 50 rows) in Gtk+? The GtkTreeView
> seemed the best a
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 w
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 bro
[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
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 ;)
>
>
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 i
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
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 sc
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 crea
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 di
24 matches
Mail list logo
