Re: Problem with a TreeView - speed

[Milosz Derezynski <internalerror gmail com>]

You mentioned fixed-height mode the first time after I did. My explanation is based on before you slipped that in. Basically in your first answer to my first or second reply or at least the one clarifying what I meant you mentioned "fixed-height mode" in a rebuttal as if that had always been the part of your explanation regarding celldata-functions, but it was not, so I (continued) trying to explain what happens in non-fixed height mode.

BTW fixed height mode imposes a few restrictions and is not always suitable, and it doesn't neccessarily mean that "one has to make a balance between flexibility and speed" because with fixed-height mode you also get fixed column widths which is the bigger problem.

On Tue, Mar 17, 2009 at 10:22 PM, Murray Cumming <murrayc murrayc com> wrote:

On Tue, 2009-03-17 at 19:02 +0100, Milosz Derezynski wrote:
> I've already defined visited: "more precisely, call the size vfunc; it
> does this only to have the row heights available, but unfortunately
> for most cell renderers, getting their requested size, similar to a
> widget, will require them to render the content internally, e.g.
> CellRendererText will create a PangoLayout with its text, etc." for
> each cell for each row, like I said, when the row gets added, changed
> or it is simply being scrolled

I do not understand why the cell size would need to be discovered for
every row if we are using fixed-height mode.

> The speed gain by not storing the data in the TreeModel (using
> ListStore or TreeStore or something other based on TreeModel) is
> minuscule compared to TreeView for each newly added row calling the
> size vfunc of each cell renderer for the whole row (I believe there
> even isn't any optimization for not rendering/size-getting what is
> horizontally not visible yet), which for almost all default renderers
> basically means rendering their content; maybe not for
> CellRendererPixbuf, and I'm absolutely not sure about
> CellRendererCombo but Text in any case yes.
>
> On Tue, Mar 17, 2009 at 11:21 AM, Murray Cumming <murrayc murrayc com>
> wrote:
>         On Mon, 2009-03-16 at 19:49 +0100, Milosz Derezynski wrote:
>         > Sorry, I somehow skipped explicitly stating the point: There
>         is no
>         > such thing as "invisible" rows with TreeView, because at
>         least once,
>         > they will be visited. Whether you use a cell data func or
>         not
>         > practically makes no difference at all, at least for that
>         particular
>         > problem.
>
>
>         How do you define "visited"? The cellrenderers will not be
>         rendered if
>         you using set_cell_data_func() and fixed-height mode. A
>         GtkTreeIter is
>         nevertheless created and destroyed in a loop for each row but
>         that's
>         insignificant in comparison.
>
>         And using set_cell_data_func() avoids copying your data into
>         the model,
>         which is obviously a performance win.
>
>         --
>
>         murrayc murrayc com
>         www.murrayc.com
>         www.openismus.com
>
>
>
>
>
> --
> Please note that according to the German law on data retention,
> information on every electronic information exchange with me is
> retained for a period of six months.
> [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung
> zufolge
> jeder elektronische Kontakt mit mir sechs Monate lang gespeichert
> wird.]

> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
--

Murray Cumming
murrayc murrayc com

www.murrayc.com
www.openismus.com

-- 
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]