This function updates a hierarchy if the layout of some widgets changed. It does
nothing on the parts that did not change. This should be more efficient than
recomputing the whole hierarchy whenever something changes.
Once again, this has some positive results on the "benchmark test":
Before:
create wibox: 0.083016 sec/iter ( 13 iters, 1.161 sec for benchmark)
update textclock: 0.00391091 sec/iter (271 iters, 3.219 sec for benchmark)
relayout textclock: 0.00273234 sec/iter (397 iters, 1.087 sec for benchmark)
redraw textclock: 0.0010191 sec/iter (989 iters, 1.745 sec for benchmark)
After:
create wibox: 0.083146 sec/iter ( 13 iters, 1.163 sec for benchmark)
update textclock: 0.00170519 sec/iter (647 iters, 2.201 sec for benchmark)
relayout textclock: 0.000581637 sec/iter (1880 iters, 1.094 sec for benchmark)
redraw textclock: 0.0010167 sec/iter (997 iters, 1.773 sec for benchmark)
So again no difference for creating wiboxes (100.16% compared to before). This
time we also have no real difference for creating wiboxes (99.76%). Update (44%)
and relayout (21%) are improved a lot.
Closes https://github.com/awesomeWM/awesome/pull/463.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the textbox' :draw() and :fit() callbacks use the DPI that is
specified in the given drawing context. With this, the textbox now scales
correctly if different screens have different DPI values.
Idea originally from Daniel.
Closes https://github.com/awesomeWM/awesome/pull/457.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This has some positive results on the "benchmark test". Each single number is
the best one out of three runs.
Before:
create wibox: 0.0826502 sec/iter ( 13 iters, 1.157 sec for benchmark)
update textclock: 0.0186952 sec/iter ( 57 iters, 2.473 sec for benchmark)
relayout textclock: 0.0158112 sec/iter ( 64 iters, 1.028 sec for benchmark)
redraw textclock: 0.0015197 sec/iter (662 iters, 1.861 sec for benchmark)
After:
create wibox: 0.0825672 sec/iter ( 13 iters, 1.154 sec for benchmark)
update textclock: 0.00378412 sec/iter (277 iters, 4.216 sec for benchmark)
relayout textclock: 0.00259056 sec/iter (420 iters, 1.09 sec for benchmark)
redraw textclock: 0.00105128 sec/iter (958 iters, 1.79 sec for benchmark)
We see no significant change in the creation of wiboxes (99.9% compared to
before). Update (20% of the previous run time), relayout (16%) and redraw (69%)
are all sped up by this change.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, dependencies between widgets where implicitly discovered by
recursive calls to base.fit_widget() and base.layout_widget(). However, it is
too easy to get this wrong (just call one of these functions from outside of a
widget's :fit() / :layout() function) and the resulting mess would be hard to
debug.
Thus, this commit changes the API so that callers have to identify themselves
and we can explicitly record the dependency between the widgets involved.
This also fixes a bug where no dependencies were tracked for widgets after
:set_visible(false). Whoops...
Sorry for breaking the API for adding this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a complete repaint is scheduled, also do a relayout, because this is also
the case that we go through when the underlying cairo surface is resized. For
example, resizing a client with a titlebar would trigger this.
Also, going through this code path is necessary since this is the only place
where the dirty area is updated so that it includes "everything". Before this
change, nothing was actually redrawn, because the dirty area was empty.
Fixes: https://github.com/awesomeWM/awesome/issues/449
Signed-off-by: Uli Schlachter <psychon@znc.in>
This accidentally called the draw callbacks with a nil argument instead of the
context. This was introduced in some badly done rebase, sorry! :-(
Signed-off-by: Uli Schlachter <psychon@znc.in>
The parent was needed for :get_matrix_to_device() which recursively walked
parents and multiplied together their transformation matrices. This is now
replaced by calculating all these matrices while constructing the hierarchy.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There once was a function :get_root() on hierarchies, but that wasn't needed any
more and thus was removed. This commit also removes the internal code that was
used to record the root element of the hierarchy.
Signed-off-by: Uli Schlachter <psychon@znc.in>
These caches, well, cache the result of the :layout and :fit callbacks on
widgets.
Clearing caches is done by recording dependencies between a widget. When a call
to base.fit_widget() or base.layout_widget() recursively causes another call to
such a function, this means that the earlier widget depends on the later widget.
This dependency is recorded and when the later widget emits
widget::layout_changed, the caches of all the widgets involved are cleared.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A widget hierarchy describes the position of widgets. The hierarchy is a
recursive tree of widget hierarchy instances. This functionality depends on a
:layout function that is not yet implemented on widgets, but will be added
later.
Signed-off-by: Uli Schlachter <psychon@znc.in>
After this change, fit_widget() enforces that a widget cannot ask for more space
than was offered to it. This also fixes a rounding issue in the flex layout
where its fit function would return too small numbers.
Thanks to this, lots of "XXX" comments in spec/ disappear.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In expand nodes "none" and "outside", the variable size_remains describes how
much space is available for the first/third widget. Everything else is used by
the second widget. Thus, fitting the second widget to anything involving
size_remains is wrong. Instead, this commit uses the correct value.
This also fixes a messed up argument order for horizontal align layouts.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This table contains the drawable, wibox and titlebar that we are drawing on, but
also includes the screen and the DPI of that screen. This allows widgets to
depend on the DPI in their rendering.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Having two modules named "base" is confusing and "wibox.layout" doesn't contain
much useful stuff. This is a first step for removing wibox.layout by moving a
function which should only ever be used internally in awesome.
Signed-off-by: Uli Schlachter <psychon@znc.in>