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=details&task_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.
