Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Tristan Van Berkom <tristanvb openismus com>]

On Sun, 2010-10-31 at 17:30 +0100, Kristian Rietveld wrote:
> On Sun, Oct 31, 2010 at 7:21 AM, Tristan Van Berkom
> <tristanvb openismus com> wrote:
> > Ok so I'm pretty much finished the request/allocation code... I've got
> > as far as having a list of renderers with allocated positions and sizes
> > come time for ->render()/->event() etc.
> >
> > If I understand correctly about cell_area vs background_area, the
> > difference is basically only the focus line width... the reason for
> > this is that we want cells to be allowed to fill the whole background
> > area with a possible background color before we go ahead and pain a
> > dotted focus line over the possibly modified background area.
> 
> That the focus line width is the only difference is true as far as
> GtkTreeViewColumn is concerned.  Outside of that, there is more,
> GtkTreeView will calculate cell_area from background_area taking into
> account vertical-separator, horizontal-separator style properties,
> depth of the current row, expander indent settings, etc.
> 
> > so currently the api on the GtkCellArea only takes a single cell_area
> > when rendering, I think thats going to be fine in general and make for
> > a clearer API (let me know if I missed something).
> >
> > So for this I'd like to add a "focus-line-width" property to the
> > base class GtkCellArea, and just make the cell area implementations
> > always request space for focus-line-width around cells ... then
> > come time to render we just create a background/cell_area based
> > on the focus-line-width and pass both areas to
> > gtk_cell_renderer_render()... I'll do that part presently.
> 
> Reversing the calculation, so calculating background_area from
> cell_area, will not always work as far as I can see now.  There's more
> to take into account than just focus line width as I outlined above.
> background_area has slightly different semantics than just cell_area +
> focus line width + separators in some cases.  I cannot precisely
> answer the question right now, but when reviewing the branch, I will
> have to compare GtkCellAreaBox with
> gtk_tree_view_column_cell_process_action() anyway, after which I can
> go into more detail.  I should perhaps look into bringing this stuff
> under unit test at the same time ...
> 

Ok what I have now in git is basically some  "cell-margin"
(left/right/top/bottom) properties configurable on the base
GtkCellAreaClass... all cells make their requests inclusive
of the margins and then at render time one can simply strip
the margins from the background area to produce the cell
area.

>From what I understand reading the treeviewcolumn code, this
is good enough for a single GtkCellArea.

So that means that ofcourse in a treeview, one has mulitple
treeview columns each containing a cell area, it will be up
to the treeview(column) to calculate the rowdata depth and 
offset the render rectangle, and also to space the columns
out... and add any specific row spacing... all of that can
be accomplished by modifying a single rectangle and providing
it to the GtkCellArea at render time as far as I can see.


> > /* When an allocated width for a height for width treeview changes,
> >  * its important to flush out the previous results (or when we
> >  * allow the width of the treeview to shrink in consequence of
> >  * data updates and we may want to re-request the whole thing),
> >  * for this we have:
> >  */
> > void gtk_cell_area_iter_flush (GtkCellAreaIter *iter);
> > void gtk_cell_area_iter_flush_preferred_width (GtkCellAreaIter *iter);
> > void gtk_cell_area_iter_flush_preferred_height_for_width
> >                                        (GtkCellAreaIter *iter,
> >                                        gint             for_width);
> > void gtk_cell_area_iter_flush_preferred_height (GtkCellAreaIter *iter);
> > void gtk_cell_area_iter_flush_preferred_width_for_height
> >                                        (GtkCellAreaIter *iter,
> >                                        gint             for_height);
> 
> Note that I haven't looked into the actual code yet (hope to get to
> that during the week), but one of the questions will be how much data
> is exactly cached and how?  GtkTreeView currently employs a RBTree to
> efficiently cache/store height data and I think we would want to avoid
> having more data structures next to that caching similar or related
> data as that might not help performance.  (I am thinking 10000+ row
> tree views here).
> 

It doesn't cache much at all and depends on the CellArea implementation,
for instance a GtkCellAreaBoxIter caches the aligned minimum and
natural widths of every group of cells leading up to an aligned cell.

That's what potentially allows us stuff like:

[ Some variable length text ] [ ICON ] [ Text in an aligned cell ]
[ Shorter text ] [ ICON ]              [ Other text in an aligned cell ]

Perhaps 'invalidate' would have been a better word than 'flush' here ;-)
(since flush seems to imply there's lots of data to get rid of)

Cheers,
        -Tristan

> 
> 
> regards,
> 
> -kris.