Up to now, a drawable always figured out the screen that it is on by
looking at its position. This causes memleak-like problems with wibars:
A wibar has a screen assigned, but its underlying drawable will end up
referring to another screen. Via this, we were managing to build a long
reference chain of screens and drawable that meant that none of the fake
screens that our test suite added could be garbage collected.
To fix this, add wibox.drawable._force_screen(s). After this function is
called, the normal screen detection based on the position is skipped and
instead the given screen is always used. This breaks the above reference
chain and things become garbage-collectable.
Also, this chains the drawable to the life time of the screen: When the
screen becomes invalid (.valid == false), the drawable will stop
redrawing.
Fixes: https://github.com/awesomeWM/awesome/issues/1237
Signed-off-by: Uli Schlachter <psychon@znc.in>
It does not provide much value. The version number is already known to
ldoc globally in the "description" variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of matrix_to_device and matrix_to_parent, this now provides the
full hierarchy instance managing the current widget.
In addition to x, y, width and height (which are an over-approximation
of the widget's extents on the drawable), this now also provides
widget_width and widget_height in the widget's local coordinate system.
These last two values are exact.
For example, the tooltip needs x/y/width/height while a widget that
wants to figure out which point on it was hit with a mouse press will
need widget_width and widget_height (together with the position argument
that is passed in with mouse::press).
I don't know how to document the return type of this function properly.
Hopefully just describing the structure of the resulting table is good
enough.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similar to the previous commit, this makes the drawable not apply a
pending relayout while it is not visible. When it becomes visible again,
the relayout is done.
The hope here is that less work is done while a drawable is not visible,
saving CPU time.
Signed-off-by: Uli Schlachter <psychon@znc.in>
LGI does not protect against use-after-free issues that can occur due to
using an object after finalisation. This manifests itself as occasional
crashes on Travis in cairo_region_union_rectangle() (AFAIK no one ran
into this issue in real-world usage).
Since visible drawables are always strongly reachable, the issue can
only occur with invisible drawables. The previous commit made sure that
those are fully repainted when they become visible, so we can just
ignore redraws for those and fix the crash issue.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of tracking all drawables that are alive, the code now only
tracks visible drawables. When a drawable is made visible it is
completely repainted. This should not cause a difference when a wibox is
initially made visible, because it has to be redrawn anyway. However,
this introduces a full repaint when a wibox is hidden and then made
visible again.
Thanks to this change, we can stop using weak tables. Visible drawables
cannot be collected and so we can keep a strong reference to them. This
allows us to get rid of the weak tables which solves various problems
involving finalizers and using objects after finalisation.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This new function is called whenever the visibility of the drawable
changes. Later commits can use this for explicitly tracking the lifetime
of drawables instead of using magic weak tables.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Twice now we had problems with the garbage collector which caused signals
established via weak_connect_signal() not to be disconnected when we wanted them
to be disconnected. The effect was that we tried to redraw a drawable after it
was garbage collected which caused errors.
Instead of playing whack-a-mole with all the various ways that might make us
redraw a drawable after GC, let's just fix all of these issues by explicitly
checking for this case and turning it into a no-op.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit made wibox.drawable turn a "normal redraw" into a complete
repaint when it was moved to another screen. However, nothing happened until
that normal redraw.
This commit triggers a normal redraw when we are (possibly) moved to another
screen. More precise, this means that whenever a screen appears, disappears or
changes its geometry and when the drawable is moved, we trigger a normal redraw.
This redraw will likely do nothing, because no relayout is pending and no part
of the surface needs a redraw, so it is cheap.
However, if the drawable really ends up on another screen, then the code from
the previous commits makes us do a full relayout and redraw.
This commit likely fixes the current instability of test-screen-changes.lua. See
https://github.com/awesomeWM/awesome/issues/982#issuecomment-231712056.
As explained there, the test fails because the fake screen that it created is
still referenced, so cannot be garbage collected, but the test doesn't succeed
unless the screen is garbage collected. So something is still referencing the
screen that was removed. This something can be a client's titlebar, because the
underlying drawable still has a context member referring to the old screen.
This commit should fix that problem, because we now trigger a redraw which will
compute a new context and thus the reference to the old screen is released.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit made the hierarchy do a re-layout when the context changes.
However, widgets could change their appearance depending on the context without
changing their layout. Thus, the previous commit is not enough.
This commit also makes the drawable redraw everything when the context changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
widget_at() no longer exists since 0aa4304bda (and the surrounding commits
stopped us using this function).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The actual bg is drawn either with fake transparency over the wallpaper (this
uses operator OVER) or for true transparency with operator SOURCE. The bgimage
should be drawn ontop of this without erasing the background and thus needs
operator OVER.
However, before this commit the bgimage was drawn in the same way as the bg and
thus inherited its SOURCE operator if a compositor is running. Fix this by
restoring the default operator (OVER) and also e.g. the default source before
drawing the bgimage.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
When called with the file name of an image, this function failed to turn that
file name into a cairo surface.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
The requirement to call add_signal() was added to catch typos. However, this
requirement became increasingly annoying with property::<name> signals and e.g.
gears.object allowing arbitrary properties to be changed.
All of this ended up in a single commit because tests/examples fails if I first
let add_signal() emit a deprecation warning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When there are no screens, screen[1] causes an error. Thus, this isn't a safe
fallback for these functions. Instead, this commit makes the code prefer the
primary screen, if possible. If no screen exists, then screen.primary will be
nil, but at least it won't throw an error like screen[1] does.
(This also changes the outdated copy of getbycoord that exists in
wibox.drawable)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit documents that a textbox already accepts a screen object where a
screen index is expected. Also, this changes the widget API in that a widget's
context.screen is now a screen object instead of a screen index.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It's unused since commit 0aa4304bda. Before this was a stable sorting
algorithm since table.sort is allowed to be unstable. Apparently we don't need a
stable sorting algorithm anymore.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
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 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>
This way "that other widget" doesn't prevent the current widget from being
garbage collected.
Please note that this in all of these cases the widget under consideration does
have a strong reference to the callback function. This means that the callback
cannot be garbage collected until "this widget" itself is collected. Thanks to
this, this change is safe.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Uli Schlachter
MoreThanOneAnimal
Emmanuel Lepage Vallee
Daniel Hahler
Grigory Mischenko
kindlycat
Daniel Hahler
Julian Wollrath