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, ). 
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:

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

Reply via email to