THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#1296 - Updated signal causes total relayout
User who did this - Emmanuel Lepage Vallee (Elv13)
--
Yes, you are right. The widget::updated signal is propagated back up, then,
when it reach the upper layer, register a callback to be executed during the
next event loop cycle. This avoir widgets redrawing themselves multiple time
during the same event loop cycle (that's uselsss). This have the bad side
effect of causing exessive redraw. This is a serious issue and indeed prevent
advanced animations from being implemented (trust me, I know this,
https://raw.githubusercontent.com/Elv13/radical/master/screenshot/all.png ).
One early attempt at solving part of this issue was implemented in 3.5.3. It
was to prevent useless :fit() calls, but did not improve on the useless :draw()
calls. Another fix was to lower the CPU overhead of Cairo calls. This was
implemented in LGI 1 year ago, but was only recently released (0.8). This
actually solve most of the consequences, but not the issue itself. Yet another
workaround is to use LUAjit rather than LUA for both LGI and Awesome.
That being said, this is still a serious issue and something that reduce the
scope of Awesome to simple presentation and must be solved. My naive guess
would be that if :fit() return the same value as the previously used one, then
only that sub section need to be registered to be redrawn using the previous
geometry parameters. This, in turn, need to support the 1 widget, multiple
instances case where a single widget can be added to multiple wibox.layout.
The second corner case is when the :draw() method ignore its region, unset its
clip and draw outside of its limits. This is used for things like grow on
hover effects and the PowerLine arrow used in the screenshot above. Finally,
an other bugs that would get worst with this solution is the fact that the
layout system doesn't round its pixel area. Some draw are often called with a
starting point midway in a single pixel. The result is then blended with other
widgets. This is a bug, but it isn't this bad with the current redraw
everything everytime rendering code. This bug would also need to be solved
after implementing the region damage code path.
I think it can be done without breaking the current API too much. Historically,
Awesome break API all the time, so as long as it is not outragiously different,
it can get merged anyway. It will need a good system to track each widget usage
from the widget itself, a way for the parent layout to cache the current widget
size and a new event loop callback to redraw the regions themselves. Uli
(psychon) is probably in a better position to tell us why it wont work, but as
far as I know it should be possible.
--
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1296#comment4128
You are receiving this message because you have requested it from the Flyspray
bugtracking system. If you did not expect this message or don't want to
receive mails in future, you can change your notification settings at the URL
shown above.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
