Re: GSK review and ideas

[Owen Taylor]

On Thu, 2016-12-15 at 16:26 +0100, Alexander Larsson wrote:
> This combined with the fact that OpenGL makes it very hard, flickerly
> and generally poorly supported to do damage-style partial updates of
> the front buffer means we should consider always updating the entire
> toplevel each time we paint. This is what games do, and we need to
> make that fast anyway for e.g. the resize case, so we might as well
> always do it. That means we can further simplify clipping in general,
> because then we always start with a rectangle and only clip by rects,
> which i think means we can do the clipping on the GPU.

Just because we need to be able to repaint the whole toplevel quickly
for resizing and other animations, and just because games repaint the
whole scene - that should not drive an assumption that there is no
value to clipped updating. Clipped updating is not done for speed -
it's done to reduce power consumption and to leave resources (GPU, CPU,
memory bandwidth) for other usage.

If a copy of Evolution in the background is using only 25% of system
resources to update a small progress bar at 60fps, that's not "60fps -
success!", that's "2W of power - fail!"

- Owen



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSK review and ideas

[Alexander Larsson]

On tor, 2016-12-15 at 11:22 -0500, Matthias Clasen wrote:
> 
> 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.

True, but we must have *a* clip which we know of a-priore, it can't be
unbounded.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a jaded Republican barbarian whom everyone believes is mad. She's a 
sharp-shooting nymphomaniac angel who hides her beauty behind a pair of 
thick-framed spectacles. They fight crime! 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSK review and ideas

[Matthias Clasen]

On Thu, Dec 15, 2016 at 10:26 AM, Alexander Larsson  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 1s 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

GSK review and ideas

[Alexander Larsson]

I just read through the wip/otte/rendermode branch, and I must say I
really like it. It makes it very explicit that the rendernodes are
immutable. For instance, there is no "append" operation or any setters
for any data (other than the mostly-debug name). I also like that it
has several types of nodes, because it makes it much easier to reason
about the semantics of it. If you have a single node with a bunch of
options it is very hard to understand how they combine, and i'm pretty
sure there would be cases where e.g. the cairo and the GL backend
disagreed on this.

However, I don't think the branch goes far enough. There are several
more changes I'd like to make:

First of all, I think GtkSnapshot as-is doesn't make sense in gtk. It
is a natural companion to GskRenderNode, and should live next to it
(modulo some tiny helpers for css rendering that can stay in
gtk+). I'm thinking we can call it GskRenderTreeBuilder or something,
because its very similar to the String / StringBuilder pattern.

I think we can drop the make_immutable vfunc for render nodes now,
because no render nodes have any setters really, they are immutable
since all properties are construct-only.

I also think we should drop the get_bounds vfunc. All the child nodes
have a "graphene_rect_t bounds" already. We just need to add one for
the
containers, and calculate it during construction. Then we can push
the field up to GskRenderNode and drop a lot of indirect calls.

gsk is pretty tiny now, and it is really quite tied to gdk, in that
GskRenderer is basically they one way you're supposed to draw to a
toplevel GdkWindow. I don't really get why it has to have its own
namespace. I think we should just move all the gsk stuff to gdk. There
are no pre-existing naming conflicts, and I think it will make things
clearer.

I think the many layers of rendering are a bit confusing, there are so
many different _begin_frame() calls. One obvious cleanup here would be
to break out the cairo fallback handling in GdkWindow into a
GdkDrawContext we could use instead of the GL one, then we can get rid
of code like:

  if (draw_context)
gdk_draw_context_begin_frame (draw_context, real_region);
  else
gdk_window_begin_paint_internal (window, real_region);



The only thing you use GskRenderNode objects for now is to create a
tree of them and hand that off to a GskRenderer for rendering of a
frame. All the other operations on the tree (other than the debug
stuff in the inspector) is handled purely inside gsk/gsk. For
instance, there is no reason to hang on to a render node for any other
lifetime than the rendering of the frame. Having all this code doing
atomic operations to refcount the nodes during construction, then
nothing, then atomic refs for every node after the frame is done seems
quite unnecessary.

Instead I propose we add a new object GskRenderTree, which create and
owns all the rendernodes that are part of the frame. The nodes would
be tied to a render tree forever and have the same lifetime as the
tree. This would allow us to very very efficiently allocate and free
render nodes. You'd just allocate a chunk of memory for the tree and
hand out references to that part of that as we create new nodes.  Then
we can free this with a few calls to free() at the end.  Most of the
data in the current render node implementations is either inline or
could easily be allocated from the same chunk of memory during
creation. The only exceptions are really cairo_surface_t and
GskTexture, but we can easily make the RenderTree own them. Then we
can also drop the finalize vfunc for the render nodes.

Its not clear to me how clipping is supposed to work. In the
traditional rendering model we always applied the widget allocation as
a clip region on the cairo_t when we propagated to a child. This meant
that no widget could ever draw outside its allocation. But in the new
world we only apply clipping when we manually emit a clip node, such
as in a viewport. Typically widgets don't draw outside their
allocation by default, but it could easily happen by mistake, or due
to external things like css transformations affecting what you draw.

I don't think this is necessarily a *bad* thing. In fact, it seems
like it is a more natural way from the perspective of doing cool
things. However, it violates certain properties we rely on in Gtk+,
particularly involving gtk_widget_queue_draw() and the tracking of the
dirty region (which then eventually gets passed to the renderer as a
clip). If things can draw outside the allocation, then that will not
repaint properly due to the clip-to-dirty-region.

This combined with the fact that OpenGL makes it very hard, flickerly
and generally poorly supported to do damage-style partial updates of
the front buffer means we should consider always updating the entire
toplevel each time we paint. This is what games do, and we need to
make that fast anyway for e.g. the resize case, so we might as well
always do it. That means we can further 

Re: Gtk+4.x and broadway ( and other remote options )

[Alexander Larsson]

On ons, 2016-12-07 at 14:18 +1100, Daniel Kasak wrote:
> Hi all.
> 
> I posting here in response to comments on bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=775680 ( summary: broadway
> support likely to be removed from Gtk+4.0 ).
> 
> I think it would be a massive pity to drop broadway support from gtk.
> It's been a god-send for me and those I work with - it provides the
> best remote access to gtk apps and performs way better than vnc. I've
> actually been working on an authentication + transparent proxy for
> broadway, so multiple users can access multiple apps all via https on
> port 443: https://tesla.duckdns.org/transparent-proxy-for-broadway-gt
> k3-html5-backend/

So, there are two issues with broadway.

First of all, I wrote it mostly as a proof of concept of an interesting
idea. I have zero cycles to spend on it anymore, nor do any of the
other people who currently work on Gtk+. Its still there, because it
just works and is not really a burden on the existing code unless you
use it.

Secondly, while it just keeps working in gtk3, the same is not true for
Gtk4. We're doing massive changes to the internals of the drawing
model, with the end goal of having a much more modern base targeting
how current GPU hardware works. This is very much not how broadway
works though, so there is some conflict here. For now, we have fallback
code for the rendering that keeps broadway working, so we're keeping it
around, but if at any point broadway becomes a problem to keep working
we're going to drop. I don't really forsee this happening at the
moment, but there are no guarantees.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a lonely bohemian shaman on his last day in the job. She's a 
beautiful psychic schoolgirl looking for love in all the wrong places. 
They fight crime! 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list