[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: GSK review and ideas
From:       Matthias Clasen <matthias.clasen () gmail ! com>
Date:       2016-12-15 16:22:55
Message-ID: CAFwd_vAiC7rDNTHf8u7EfRh66PffYXtGU4sWsyxeVL_=cw9yAg () mail ! gmail ! com
[Download RAW message or body]

On Thu, Dec 15, 2016 at 10:26 AM, Alexander Larsson <alexl@redhat.com> wrote:
>
> Also related to clipping, we're currently not doing any culling at
> all. I think we need to make gtk_container_snapshot_child() take the
> current clip into consideration when recursing. Right now we're
> creating nodes for children that are not visible.
>
> Of course, such culling relies on the fact that the children don't
> draw outside their allocation. Culling seems quite important to be
> able to handle 10000s of rows in a listbox. So maybe we need to
> actually clip every widget.
>
> The above kinda contradicts each other, so we need to decide what to
> do here. My hunch is that the natural approach is a bit of both, where
> we always repaint the entire window (ignoring the damage region), but
> clip each widget to the allocation. That means clipping becomes a
> simple int-rect intersection (not a full region_t) which can be done
> fast (and maybe on the GPU) while still allowing highlevel culling on
> the widget allocation level. Does that seem right?
>

Note that we do have a clip rect for widgets that can be larger than
the allocation. So we can have the best of both worlds: widgets can
opt in to drawing outside their alllocation by setting a clip, and we
can still cull everything whose clip rect doesn't intersect the (gsk)
clip.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]