Re: Few questions about GL on GTK Master
On 2018-08-03 04:53, Chun-wei Fan via gtk-devel-list wrote: -At this point, it is possible to run with the GL GSK renderer while forcing EGL/GLES (i.e., setting GDK_DEBUG=gl-gles). I saw shader compilation errors for both blur.fs.glsl and color_matrix.fs.glsl on both EGL/ANGLE, as well as running with the X11 backend on Ubuntu 18.04 (the 'f' suffix for floats which are not allowed on GLSL 1.00; unresolved overloading of max() in blur.fs.glsl, invalid casts/conversions of int vs float). There were some fixes for that just recently. The status is that anything other than GL3+ (or "whatever my PC at home uses") is effectively untested. I made the ES renderer work at some point but fonts were still broken if I remember correctly. - Timm ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Does GTK+ do automated/nightly performance regression testing?
On 05.02, Clemens Eisserer wrote: > So back to the original question: How does the GTK+ project make sure > to spot performance regressions when they are introduced? > And if there is nothing automated, would there be interest in such a > project - Would it be useful and used by the developers doing feature > work? Aside from what Emmanuele already said: yes, that would be very useful. However, the performance problems in gtk4 are not that much related to rendering (mostly...), but the much bigger problem is CSS (in)validations. GTK4 does a lot more CSS state changes due to automatic focus and :hover tracking with CSS pseudo classes. While the number of CSS nodes should not have significantly increased, the fact that we e.g. set :hover on a listbox node with many children is new in gtk4. But then again, this is already known to be slower and what we need is a fix for that. Still, I think even if you can't automate it, a performance testsuite for certain things (or just a bunch of executables in tests/, really) would be good in any case. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 4: knowing the action/event at the origin of a text insertion/deletion?
On 07.07, Sébastien Wilmet wrote: > But heuristics are not ideal of course. Will the input handling rework > in GTK+ 4 support that use-case? As far as I know, the input rework so far only touches pointer input and has nothing to do with keyboard input at all. I'm not sure what Carlos and/or Christian have planned and what they will actually implement though. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Widget, drawing and event coordinates
On 12.06, Matthias Clasen wrote: > Trying to summarize an irc discussion on this topic: > > We generally agreed that the content area should be what all vfuncs > (measure, > size_allocate, snapshot), events and signal handlers operate in. > > The other size that is relevant for widgets is the 'outer' size including > the content size, > css padding, border and margin, and any extra space that the widget might > be allocated. I don't think this is exactly what Benjamin meant, i.e. we already have that with gtk_widget_get_allocated_size. > Widgets need the content size of themeselves, and the outer size of their > children. Why does "outer size" include css margins? I don't think they are ever relevant for anything, just like widget margins never really are. gtk_widget_size_allocate_with_baseline could simply remove those from the widget size just like it does with widget margins. that way we could position popovers for buttons in headerbars properly... > We should introduce new getters for content size and outer size, and phase > out > get_allocation, which is defined in terms of the parent window - not very > useful > anymore. get_allocation can return whatever we want of course, and in wip/baedert/drawing, those coordinates are not relative to the parent window, but to the parent widget's content allocation. Anyway, the new API would e.g. be 1) gtk_widget_get_outer_allocation that returns the size of the widget's content allocation plus CSS padding and border (not margin IMO). the x/y returned are relative to the parent widget's content allocation. This way, the returned allocation can directly be used to e.g. check if the given coordinates in a gesture handler are inside a (direct) child widget's border allocation (so use the current gadget terminology). 2) gtk_widget_get_some_allocation which returns the widget's content allocation, relative to it's...? To what? Ideally this should cover the "is the current coordinate that I got from a gesture handler even inside this widget's border allocation" use case, so the returned allocation should be relative to the widget's own content allocation and return negative x/y values. That all being said, GdkWindows won't just go away like that, we still need them for popovers and toplevel windows at least. And popovers can contain other popovers... so gtk_widget_translate_coordinates will have to handle that. Does anything enforce those windows to influence widget coordinates in any way? I've so far just encountered that having a O(1) and very-fast way of getting window-relative widget coordinates is handy for drawing invalidation. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Widget, drawing and event coordinates
On 11.06, Matthias Clasen wrote:
> On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder <m...@baedert.org> wrote:
>
> > The goal here is to unify the coordinate systems we use for events,
> > drawing and size allocation.
> >
> > Widget coordinates definitely should be relative to the parent
> > allocation in some sense, so we can move subtrees around without
> > re-allocating every single widget in it.
> >
> > In master, all event coordinates are relative to the widget allocation,
> > which excludes widget margins, but includes css margin/border/padding.
> >
> > In wip/baedert/drawing[1], currently widget allocations are relative to
> > the parent content allocation, which means the size_allocate
> > implementations get an allocation of
> > {0, 0, content_allocation_width, content_allocation_height} passed.
> >
>
> Not sure i follow here. If it is relative to the parent, why would x/y by 0?
Because we pass the content allocation of the widget to size-allocate,
so it can be used to allocate child widgets. Since that is relative to
the widget's content allocation, x/y is 0/0. The parent-relative
allocation is set before the ->size_allocate implementation is called.
> > When drawing a widget, we first offset to the widget's content
> > allocation and then call its snapshot implementation.
>
>
> Can we define a few terms here ? I would like to make sure we all have
> the same understanding of 'content', for example.
>
> Do we use this https://www.w3.org/TR/CSS2/box.html as reference ?
Yes. Content postion is the widget allocation as returned by
gtk_widget_get_allocation (atm) plus margin,border,padding.
> > As for input, the
> > events get routed to a widget if the (toplevel relative) coordinates
> > are inside the widget's margin allocation (widget allocation excluding
> > the css margins as well). The coordinates the gestures (or
> > gdk_event_get_coords) report however, are relative to that widget's
> > content allocation, i.e. the values will be negative inside the widget's
> > padding and border[1].
> >
>
> I don't think there is any problem with negative coordinates, apart from
> not being used this happening ?
Probably, yes.
> >
> > So using the content allocation in size_allocate and snapshot
> > implementations makes IMO perfect sense. One problem now is that
> > gtk_widget_get_allocation (and the still private get_margin_allocation,
> > get_content_allocation and get_border_allocation) are not relative to
> > the widget's content allocation but to the parent's (since that's the
> > coordinate space passed to gtk_widget_size_allocate_with_baseline).
> > Changing this would however mean that gtk_widget_get_allocation can
> > also return negative x/y coordinates.
> >
>
> How so ? Doesn't it return the content allocation, which you said earlier is
> (0, 0, allocated-width, allocated-height) ?
No it doesn't, that's just how it is right now and one of the points to
be discussed. _get_allocation returns the widget allocation relative to
the parent's content allocation.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Widget, drawing and event coordinates
The goal here is to unify the coordinate systems we use for events,
drawing and size allocation.
Widget coordinates definitely should be relative to the parent
allocation in some sense, so we can move subtrees around without
re-allocating every single widget in it.
In master, all event coordinates are relative to the widget allocation,
which excludes widget margins, but includes css margin/border/padding.
In wip/baedert/drawing[1], currently widget allocations are relative to
the parent content allocation, which means the size_allocate
implementations get an allocation of
{0, 0, content_allocation_width, content_allocation_height} passed.
When drawing a widget, we first offset to the widget's content
allocation and then call its snapshot implementation. As for input, the
events get routed to a widget if the (toplevel relative) coordinates
are inside the widget's margin allocation (widget allocation excluding
the css margins as well). The coordinates the gestures (or
gdk_event_get_coords) report however, are relative to that widget's
content allocation, i.e. the values will be negative inside the widget's
padding and border[1].
So using the content allocation in size_allocate and snapshot
implementations makes IMO perfect sense. One problem now is that
gtk_widget_get_allocation (and the still private get_margin_allocation,
get_content_allocation and get_border_allocation) are not relative to
the widget's content allocation but to the parent's (since that's the
coordinate space passed to gtk_widget_size_allocate_with_baseline).
Changing this would however mean that gtk_widget_get_allocation can
also return negative x/y coordinates.
The question is now: does this all make sense or should we go another
way? One thing I would find useful (I haven't tried it though...) is to
also exclude css margins from the widget allocation, just like we do
with widget margins currently.
[1] See also
https://mail.gnome.org/archives/gtk-devel-list/2017-May/msg00034.html
[2] I modified tests/testwidgetfocus to showcase this
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: wip/baedert/drawing branch
On 18.05, Matthias Clasen wrote: > On Thu, May 18, 2017 at 11:52 AM, Timm Bäder <m...@baedert.org> wrote: > Hey Tim, thanks for writing this up. > > Let me ask a few questions that are unclear to me, before we discuss the > individual things: > > - What are the overall goals here ? That would be good to know. My guess > would be: > 1) Get rid of gadgets > 2) Full css drawing for all widgets > anything else ? No, that's it basically. > > - Focus outlines work out pretty badly the way they are currently done > >in the branch. Wit gadgets, widgets had pretty fine-grained control > >over which gadget draws the focus outline. > > > > How _are_ they done now ? gtk_widget_snapshot just draws it around the widget if gtk_widget_has_visible_focus returns TRUE for it: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?h=wip/baedert/drawing#n15693 So e.g. dragging on a scale slider means the entire scale gets a focus rectangle drawn, and entries get a focus rectangle drawn on top of their normal focus indication (the blue border). Dunno if we can just set can-focus to FALSE for appropriate (child) widgets and it works itself out. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
wip/baedert/drawing branch
Hi,
I've collected a whole bunch of changes in th wip/baedert/drawing branch.
Here's a little overview of how things work in there, so we can decide
if it's the right way forward.
Internals:
- gtk_widget_snapshot automatically draws CSS background and border for
all widgets. It then calls the ->snapshot vfunc so the widget can
draw contents, then it draws a focus rectangle if
gtk_widget_get_has_visible_focus returns TRUE.
- gtk_widget_real_snapshot calls gtk_widget_snapshot_child on all the
child widgets of the given GtkWidget instance. This makes sense to me
but it's already been problematic when porting GtkScale and GtkRange
away from gadgets because GtkRange didn't override ::snapshot so
GtkScale couldn't just subclass it and chain up, since it would cause
all child widgets to be drawn twice.
- gtk_widget_measure cares about CSS min-width/min-height, as well as
CSS margins, padding and borders. So
gtk_widget_size_allocate_with_baseline first sets the widget's
allocation to the given one and then passes the content allocation,
i.e. the one without CSS margin, border and padding down to the
size-allocate vfunc. I.e. in the size-allocate implementation,
widgets receive their new content allocation, not the entire widget
allocation. If they still need the widget allocation, they can call
gtk_widget_get_allocation of course since the allocation has been set
before calling ::size-allocate. There are currently
gtk_widget_get_margin_allocaiton, _border_allocation and
_content_allocation implementations private.
- For clips, all widgets *have to* currently call gtk_widget_set_clip
at the end of their size-allocate implementation.
gtk_widget_set_clip will union the given clip with the box-shadow
size and the widget allocation minus CSS margins.
- Since we always automatically set the allocation of a widget before
calling its ::size-allocate vfunc, gtk_widget_set_allocation is gone.
Widgets:
- GtkSpinButton is now a direct GtkWidget subclass that contains a
GtkBox that contains a GtkEntry and two GtkButtons. That was easier
than expected since GtkSpinButton already (partially) implemented
GtkEditable. It also means that currently the blue focus outline
around the entire spin button is broken. Dunno if there's some CSS
magic that would fix this or if that approach for the spinbutton is
just wrong.
- GtkRange is not abstract anymore. Not because I really want to but
because it was needed for GtkScrollbar. Not sure if that's right or
if we can use it as a general "slider inside trough" widget.
- GtkScrollbar is now a direct GtkWidget subclass containing a box that
contains a GtkRange. That works out mostly fine in practice but of
course people can't call GtkRange API on it anymore, so
gtk_scrollbar_get_adjustment has to be used, etc. The stepper buttons
are currently gone but since it contains a GtkBox they should be
relatively easy to add back, I've just not heard a good solution to
how we should hide/show them without the style properties.
- GtkCheckButton is now a GtkBin subclass containing a
GtkTogglebutton that contains a GtkIcon as indicator and the actual
bin child. This consequently means that GtkToggleButton API can't be
used on a GtkCheckButton anymore, which is pretty painfull for
porters, and there's not really an automatic way of fixing this since
the old gtk_tool_button_{get,set}_active for example are still valid
calls.
- GtkNotebook lost all its gadgets. There's stil some bug triaging to
be done though. I'm not sure if it doesn't suffer from being unable
to show/hide widgets in ::size-allocate now.
- The last remaining gadgets are the progress and icons in GtkEntry as
well as the handle gadget in GtkPaned, but I'd like to wait for the
event-delivery branch to get merged to master first.
- Since GtkPopover looks at the margins manually and considers them in
its ::measure implementation, popovers are currently slightly higher
(or wider, depending on the arrow position) than they should be.
Remaining problems/open questions:
- Both GtkWindow and GtkPopover are special-cased in
gtk_widget_snapshot to not draw the CSS background and border for
them, since they are just too special. Getting rid of that special
case would require porting them away from manual background drawing.
- There are lots of CSS problems now of course, e.g. GtkRevealer does
not hide its padding anymore so GtkSearchBar always leaves a few
pixels of space around, or the 4px margin around GtkMenu which is not
applied inside the toplevel instead of outside. Also GtkCheckButton
obviously.
- Focus outlines work out pretty badly the way they are currently done
in the branch. Wit gadgets, widgets had pretty fine-grained control
over which gadget draws the focus outline.
- I've had to make lots of changes to make clips work the way they do
now, but
Re: gtk4: gtk_box_pack_start()/end() porting
On 03.05, Murray Cumming wrote: > On Wed, 2017-05-03 at 14:22 +0200, Timm Bäder wrote: > > > Have some container widgets changed, or lost, some default > > > spacing/padding/margins too? For instance, it looks like > > > GtkActionBar > > > used to have some hard-coded spacing between its child widgets > > > (added > > > via gtk_action_bar_pack_start()), but not with gtk4. > > > > Yes, iirc GtkPopover with .menu and GtkFileChooserButton, etc. lost > > their > > spacing. Since GtkBox supports border-spacing via CSS now, I think > > themes should handle that instead, but Adwaita doesn't care yet. > > So, applications shouldn't generally need to specify any spacing at all > between child widgets in containers? For instance > - Gtk::Box::spacing > - margin of child widgets in a Gtk::ActionBar > - Gtk::Grid column-spacing and row-spacing > ? No, I'm talking about individual widgets, not applications and their UI[1]. The default values of the properties are gone in GTK+, but not the properties itself. GtkActionBar lost its spacing property I think, but that's just because I didn't know if there's a real use case for it, it seems like something the theme should control in this case. Right now we still have all the spacing properties in GtBox, GtkGrid, etc. as you mentioned and of course the widget margin properties you can use and they still work like they did in gtk3. [1]Even though spacing *should* probably be handled by the theme, so the theme can decide whether UIs are more spacey or more narrow, nobody has come up with a proper way for applications to specify that. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On 03.05, Murray Cumming wrote: > On Fri, 2017-04-28 at 17:50 +0200, Murray Cumming wrote: > > On Fri, 2017-04-28 at 17:20 +0200, Timm Bäder wrote: > > > I've added notes about the fill and expand child properties to the > > > migration guide: > > > https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3c > > > d5 > > > fdab685218bbac29 > > > > Thanks. I guess it's that last part about hexpand/vexpand affecting > > the > > parent widgets too that explains what I've seen so far. So there is > > really no simple mapping from the old API to the new API. Porting is > > going to be rather awkward. > > Have some container widgets changed, or lost, some default > spacing/padding/margins too? For instance, it looks like GtkActionBar > used to have some hard-coded spacing between its child widgets (added > via gtk_action_bar_pack_start()), but not with gtk4. Yes, iirc GtkPopover with .menu and GtkFileChooserButton, etc. lost their spacing. Since GtkBox supports border-spacing via CSS now, I think themes should handle that instead, but Adwaita doesn't care yet. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk4: gtk_box_pack_start()/end() porting
On 28.04, Murray Cumming wrote: > But, based on some experiments, it doesn't seem obvious to me exactly > how to replace these by setting halign, valign, hexpand or vexpand. > Could someone please add a mapping of the old fill/expand combinations > to the new halign/valign/hexpand/vexpand properties to the migrating > guide? > https://git.gnome.org/browse/gtk+/tree/docs/reference/gtk/migrating-3to > 4.xml I've added notes about the fill and expand child properties to the migration guide: https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3cd5fdab685218bbac29 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Optimizing GtkListBox for many rows
Hi, if you've ever worked with a GtkListBox that has many rows, you probably know about the performance problems. These are mostly not even related to drawing or scrolling. The biggest problem is just allocating all of those rows (bonus points if every row uses a composite template, so you have to parse XML and create all those widgets/objects, set the properties, etc.) and size allocation. And I guess basically everyone knows how mobile UIs solve (or avoid) thsi problem: they just estimate the list height, and only keep as many rows around as they need to cover the current viewport. This way obviously needs a backing model implementation (which we have now with GListModel) and a function that just takes an item and assigns the data to the corresponsing widgets etc. Earlier this year I've started to play around with such a widget-recycling listbox implementation here: https://github.com/baedert/listbox-test (don't judge my commit messages). It's currrently written in Vala (so I can write stuff faster). The repo includes a few demos which work more or less, you just have to (un)comment the corresponding lines int the Makefile. The ideal case, i.e. "all rows are visible and all rows have the same height" seems to work already. I've talked to at least 4 people about this and I know a few others have worked on an implementation, too, so I think it's better to just collect all the knowledge we have instead of smoeone writing it on their own. The current implementation faces a few problems, mainly regarding scrolling: - Of course, the scrollbar jumps around. If seen people say that nowadays, scrollbars should be seen as a rough indicator so maybe this is a non-issue but in extreme cases it seems pretty awkward to me. - Scrolling by dragging the scrollbar is completely broken if you have uneven row heights. Android solves (read avoids) this by scrolling row-by-row in those cases. I think Alex said something about this at the GTK+ BoF at Guadec. - We estimate the list size by just looking at the height of the current widgets. This means that the estimated height changes almost every time we remove/add a new row (given that rows have uneven height). I explicitly decided agains saving the height of every row we ever allocated and using that as a better estimate, because it makes the estimation much more complex (think about the row height depending on the data in the model...) and I don't want people to notoriously scroll through all the listboxes once to fix the scrolling. - We currently just pool the used widgets, i.e. we never free any of them. I'm not sure how other existing implementations solve this or if it's just not a problem at all. - IIRC Benjamin told me once that just faking widgets to A11y isn't really possible ATM. - I'm not sure if there's gtk+-internal API for this, but we'd basically need to tell the css machinery that a widget is at position i, without i being the actual current position in the widget hierarchy (so :nth-child works as expected). - Of course, this is currently completely independent from GtkListBox so we'd need to integrate it there. For reference, the Android implementation can be found at [1] and features nice methods like findViewByPredicateInHeadersOrFooters, but also lots of informative comments. I'm not sure how many of those 4KLOC Java we really need (and how many that would be in C...), but Android's ListView does much more than the current GtkListBox, like headers that stick to the top of the list when scrolled. On the other hand, I'm certain that e.g. Christian wants exactly that so if such a feature would completely change the entire implementation, we should maybe care about it from the very start. The current performance is OK I think. The repo includes a tweet-row.ui that I just copied from corebird and removed a few things, but it's still around 330 lines of XML and that works as far as I can see. I hope I didn't forget anything and I'm curious what you alll think and what solutions you have for all those problems, cheers. [1] https://github.com/android/platform_frameworks_base/blob/master/core/java/android/widget/ListView.java ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
On 27.12, Matthias Clasen wrote: Hi, over Christmas, I had some for a little side project, a new combo box. It is based on these mockups: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png Seems like these mockups (and the new combo box) should be kept in sync with general popover menus, especially wrt. the grouping behavior (i.e. separate pages in a GtkStack VS. expanding the new group downwards). I know Allan favored the latter (and there's a bug about it), but making that work for all the cases in comboboxes would be even harder. Other than that, the current behavior of popovers when changing their size isn't really what I'd like to see (i.e. changing the position when changing the size, that's really disturbing). And of course, animating the size change would be great here too. A few things I found in a quick test: - http://i.imgur.com/QAQddSD.png There are 2 problems here: on the very top of the list, there's a GtkSeparator visible and of course the undershoot (or overshoot?) indicator at the bottom while no scrolling is possible. - It seems to me like some rows (e.g. those with text fields and/or buttons in them) should not be focusable? - The Remove active button crashes testnewcombo here Other than that, I think it looks really cool and is a step in the right direction. Regards, Timm ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
