[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 - Uli Schlachter (psychon) -- Sorry, but I think that the padding should be returned from :layout() instead of :fit(). New version attached where layout returns a list of children and the padding for this widget. -- One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4210 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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 - Uli Schlachter (psychon)
--
It's time for a new version!
This one adds an API change to make Elv13 (hopefully) happy:
- widget:fit(width, height) now not only returns its desired width and height,
but also a third (optional) value: padding! The padding is a table that can
contains keys "left", "right", "top", "bottom" (each optional). Each value is
the number of pixels that should be additionally included in the clip area when
the widget is redrawn. So if you return { bottom = 10 }, the widget will get 10
more pixels to the bottom than what the layout decided for it. And all of this
works with any transformation, so you can scale such a widget by factor 1.5 and
rotate it by 45° and still the right result (well, it will include 15 pixels of
space due to the scaling, so the unit isn't really "pixels" but "user space
units")
Hopefully this is enough for any kind of glow effect, but don't forget that
other widgets could draw to that space before or after you, so weird results
can occur...
(Implementation details: In a widget hierachy, each node knows the padding for
its own widget and the padding including all the padding of its children. This
is used so that a repaint knows which parts of the hierachy it can skip and to
clip each widget to its padding)
--
One or more files have been attached.
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4209
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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 - Uli Schlachter (psychon)
--
TL;DR: I'd be interested in suggestions for the API.
Once again, here is a new version (mostly bugfixes). And once again, here is
the API that a widget can implement:
- widget:fit(width, height): As before, given a space of width x height, this
widget should return its desired width and height
- widget:draw(wibox, cr, width, height): As before, the widget should draw
itself on the cairo context cr in the are from (0, 0) having size (width,
height)
- widget:before_draw_children(wibox, cr, width, height) and
widget:after_draw_children(wibox, cr, width, height): These are called
before/after children are painted. before_draw_children is basically the same
thing as draw and exists just for consistency. Here the widget can e.g. call
cr:set_source_rgb(0,1,0) to influence its children. And after_draw_children()
could be used for... things. Someone will come up with a use! ;-)
- widget:layout(width, height): This returns the layout of the children of the
widget. This should return a list of widget placements. Such a placement can be
generated via base.place_widget(widget, matrix, width, height) where Matrix is
a cairo matrix that describes placement and rotation of the widget inside of
its parent's area. Most commonly such a matrix should come from
require("lgi").cairo.Matrix.create_translate(x, y) to place a widget at (x, y).
In contrast to the current area, none of these callbacks are recursive / should
call other widgets. The wibox code does all of that for us.
If a widget needs to be redrawn, but neither its :fit() nor :layout() changed,
then it should emit widget::redraw_needed.
If a widget's layout changed, it has to call widget::layout_changed. Only if
the result of its :fit() or :layout() actually changes will its :draw() also be
called, else it is assumed that no redraw is needed.
A BVH tree is an implementation detail, I'm mostly curious what exactly you
mean with "a widget can claim any space on the wibox". Or rather, how that
translates into API.
--
One or more files have been attached.
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4199
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.
[awesome bugs] #1296 - Updated signal causes total relayout
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) -- The minus-pixel/over pixel would work, however if region A is painted over by region B, then if region A is repainted, how is region B noticed? (random thought, I didn't look at the implementation). It currently work because the paint order is very predictable. As for the scroll, I guess you meant surface, not wibox. In that case the redraw code still need to take into consideration what is visible and what is not, so it can only partially work. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4172 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Uli Schlachter (psychon) -- Ok, glad that I seem to make sense and that you understand me. However, I don't feel like I understand your proposal, sorry. (How do widgets claim arbitrary space on the screen? How important is the BVH tree to your implementation?) What "feels" importing to me is that layouts/magic like we have them currently are possible: - The background (through explicitly drawing something) and foreground (by setting the cairo context's source) can be controlled for other widgets. - Widgets can be rotated and scaled (and currently an arbitrary transformation is possible, although that might not be all that important/useful). Take your time to come up with some proof of concept, perhaps I'll understand better then. No hurry. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4171 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Vlad Leberstein (owl) -- Psychon, I understand your approach and its limitations. Thats why I believe we should decide now if widget should be allowed to draw anywhere it wants because the whole GUI implementation heavily depends on this decision. I already described the way multi-region widget system can be implemented IMO, but didn't have time to do it yet. I'll try to show the working proof-of-concept at the end of the week. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4170 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Uli Schlachter (psychon) -- The area outside of the "dirty_area" in my code is not redrawn at all. So if a widget unsets the clip and draws a shadow outside of the dirty_area, the shadow won't be drawn on the background color, but ontop of the previous shadow. So on each redraw the shadow would become darker and darker. (but now I wonder what would happen if a layout places a widget outside of its own area. The dirty_area would be updated correctly and I wonder if the clipping would also Do The Right Thing(tm) for the shadows. Could this be a good idea for implementing this? What I mean exactly: The layout returns 10, 10 for :fit(), but places a widget from -5,-5 with size 20, 20 in :layout(). This could actually work, right?) Elv13: Do you want a clever scrolling layout or something similar to what is implemented in FS#1218? IMO a clever scrolling layout would make itself incompatible with the systray and use something like an "invisible wibox" where it draws its child to. In its own :draw() method it would then just copy the right part of that "invisible wibox" over. That's the best implementation I can think of after thinking about it for 0.5 seconds. Something like "real scrolling" where it moves the already-drawn part and redraws the rest might be a lot harder to implement and I'm not sure if it is worth it. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4169 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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) -- We also have to take into account scrolling layout: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1218&project=1&order=id&sort=desc&pagenum=3 -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4167 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Vlad Leberstein (owl) -- Psychon, I finally got some time to try your approach and it seems very reasonable to me. But could you please explain, why painting outside of the dedicated widget region is not related to partial redraw system? I believe that they are quite interconnected and I completely forgot to ask about it earlier :( -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4166 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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 - Uli Schlachter (psychon) -- Yet another new version of this proof of concept. Now, after re-layouting things, only the part of the wibox which really changed are redrawn. I bet this breaks Elv13's "let's ignore the widget's bound and unset the clip"-magic. I also fixed things so that the wibox code automatically emits widget::layout_changed on parent widgets when it is emitted on a child. (There is still potential for optimizations: If a widget is visible in n places, these signals will be emitted n times. This gets us exponential behavior for deep widget hierarchies. However, I do not care enough to do anything about this and this should still behave way better than what we had before.) Oh and since I didn't mention it yet: This code creates a cairo surface, places some widgets on it, forces a redraw of one of these widgets, then forces a relayout for one of the widgets and finally saves the resulting cairo surface to "out.png". During this, it prints a message each time it calls a widget's callback to show that just the minimum amount of callbacks are generated. -- One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4160 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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 - Uli Schlachter (psychon)
--
Seems like I can't get this out of my head...
All of a widget's callbacks are now optional. Missing draw methods are just
skipped. A missing :layout() is the same as returning {} aka "no children".
When :fit() is missing, :layout() is used and the area covered by child widgets
is used for the return value.
(Oh and base.fit_widget() now also forces widgets to return a value between 0
and the given width/height)
--
One or more files have been attached.
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4159
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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Uli Schlachter (psychon)
--
Sorry for spamming.
I tested a 45 degree rotation and quite some code broke. Here is the code for
the rotation:
local custom = base.make_widget()
function custom:fit(width, height) return width, height end
function custom:draw() end
custom.before_draw_children = custom.draw
custom.after_draw_children = custom.draw
function custom:layout()
local m = cairo.Matrix.create_translate(30, 30)
m:rotate(math.pi / 4)
m:translate(0, -30)
return {
base.place_widget(f, m, 30, 10),
}
end
And here are the needed fixes:
function wibox:damage_area(x, y, width, height)
local rect = cairo.RectangleInt({
x = math.floor(x),
y = math.floor(y),
width = math.ceil(width),
height = math.ceil(height)
})
self._dirty_area:union_rectangle(rect)
end
function wibox:_widget_needs_redraw(widget_state)
-- We have to transform this widget's geometry into global coordinates
local m = cairo.Matrix.create_identity()
local state = widget_state
while state ~= nil do
m:multiply(m, state.matrix)
state = state.parent
end
-- XXX: How can this be done nicer?
local x1, y1 = m:transform_point(0, 0)
local x2, y2 = m:transform_point(0, widget_state.height)
local x3, y3 = m:transform_point(widget_state.width, widget_state.height)
local x4, y4 = m:transform_point(widget_state.width, 0)
local x = math.min(x1, x2, x3, x4)
local y = math.min(y1, y2, y3, y4)
local width = math.max(x1, x2, x3, x4) - x
local height = math.max(y1, y2, y3, y4) - y
self:damage_area(x, y, width, height)
end
--
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4158
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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 - Uli Schlachter (psychon) -- Another new version. This now introduces a layout cache similar to the fit cache. This removes the "wibox" argument for :fit() and :layout() since the result of these functions is cached and thus must not depend on the wibox. This also changes the API for :layout() so that it is no longer recursive. Instead, :layout() returns a table that describes all "child widgets" together with their positions and transformations. This table is cached. This change should also make it much easier to test things. You guys don't have to look through all the code in there, but it would be nice if you looked at the "fixed" and the "img" widgets in there (lines 269 to 359) and tell me if the API they use looks sensible. The other 250 lines in there just implement this API. Oh and another new change: The result from :fit() goes through math.ceil(). This should make it harder for introduce non-integer positions for widgets, although this is still easily possible... -- One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4157 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Vlad Leberstein (owl) -- Thanks for all the replies! It's nice to see the problem gets more attention! As for the reference implementation, I need some time to fully grok what actually happens. At first glance your suggestion looks quite similar to what I came up with some time ago (except instead of :before_- and :after_draw_children I used draw coroutine :D)and it didn't work quite well because I couldn't find a suitable way to handle off-widget drawings(but my impression might be wrong). Now I'm working on some proof-of-concept implementation too. The basic idea is: each widget consists of one drawing function(which are hierarchical in the same sence as current widget tree) and many regions, which are managed by it. Each widget can claim any screen space to be managed by it(i.e. region) and wibox dynamically creates/updates BVH tree for all the regions to efficiently traverse widgets, affected by "dirty region". -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4156 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Uli Schlachter (psychon) -- Oh and the systray needs some special magic as well since awesome can only place it, not redraw it. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4155 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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 - Uli Schlachter (psychon) -- Attached is a quick prototype implementation of this. It only depends on gears.object and lgi. A widget has this callbacks: - :fit(wibox, width, height): Returns width and height that the widget wants to have, is called to assign sizes, must not have any side effect - :layout(wibox, width, height): Is called when the widget should place its children, must call base.place_widget(wibox, widget, matrix, width, height) for each child. Can use base.fit_widget(wibox, widget, width, height). Matrix transforms from this widget's coordinate space into the children's space. - :draw(wibox, cr, width, height) (and before_draw_children, after_draw_children): This is called when the widget should be drawn. This should just draw this widget on the given cairo context and doesn't have to interact with children. The two *_draw_children() do what their name suggests and can be e.g. used to set the cairo context's foreground color. Signals: - widget::redraw_needed: The various draw methods have to be called again. Only widgets which cover the same space are redrawn. - widget::layout_changed: Well, yeah, the layout needs to be changed. TODO: This still needs some magic to cache sub-layouts. Just like :fit() is cached in base.fit_widget, :layout() should be cached in base.place_widget() and this cache should only be invalidated from the widget::layout_changed signal. New compared to what we have right now: Layouts don't need to connect to any signals of their child widget since the wibox code does that for them. (The wibox code has to do this since it needs to figure out which area to redraw and I want to keep the widget hierachy private. But I bet someone will want to export it...) -- One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4154 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Uli Schlachter (psychon) -- Uhm, a quick question: How much influence would this have for real-world widgets? Whenever a widget changes its size, we will need to relayout. A textbox will always have to relayout whenever something changes. An imagebox will always have to relayout whenever the size of its image changes. Pretty much everything else builds upon these widgets and thus we will always have to relayout. So... to make this more useful, we would also need to cache layouts of widget just like we currently cache the results of :fit(). Which makes this more complicated as well, right? -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4153 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Uli Schlachter (psychon) -- Is having multiple parents worth it: Even the default config makes use of this. It's a great feature usability-wise IMO. Paint outside of the dedicated region: This is orthogonal to this bug report. I'll ignore this for now and at the end of the discussion we can think about this. How can this be solved? Currently we are lazy and when something says "I changed", everything is repainted. This is what you guys want to avoid. If we throw away multiple parents: A widget now has a unique geometry. Thus it could say "this part of me changed" and layouts would be responsible for correctly transforming this information and passing it on. We'd have to split up the relayout and the redraw phase. For relayouts I'd continue to be lazy and just re-layout everything followed by redrawing everything. It might be possibly to fix this up later on to have less redraws needed. The redraw has to be passed around like it is currently so that things like wibox.widget.background continue to work. wibox.layout.base.draw_widget() could be made more intelligent and skip the redraw if the widget does not touch any dirty area. If we keep "no unique parent per widget": This is complicated. We definitely need to split up the relayout and redraw phases as well, because input handling needs widget positions and currently this is collected during redraw. This just cannot work with partial redraws. Due to lazyness, I'd propose keeping the widget::updated signal which means "I need relayout and redraw". The wibox could contain a hierachy of widgets and when a specific widget is re-layouted, wibox.layout.base.SOME_FUNCTION throws away its subtree in this hierachy. For layouts I'd add a widget::redraw signal which skips the relayout and only does a redraw. That signal would need to contain some damaged area in widget coordinates. Uhm When would we need to relayout without redrawing? It might be possible to do this without breaking "leaf widgets" that do not try to paint other widgets. We'd split things up into two phases. First wibox.layout.place_widget + a :layout() method could be used to assign geometry to all widgets. In this phase, :fit() can be used the way it is used currently to figure out how much space a widget needs. In the second phase :draw() is called the way it already works currently. Uhm... nope. This would break wibox.widget.background. Perhaps two new optional callbacks, before_draw_children() and after_draw_children() and the wibox code does all the drawing based on the already-computed layout? I just wrote this down without first thinking about this. What do you guys think? Did I forget something? Should I try producing a small proof of concept for this? -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4152 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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) -- The bottleneck is the exponential overhead caused by LGI. This is much better with 0.8, but far from perfect. So lets break your questions into smaller ones: > Is having multiple parents worth it? Yes and no. Awesome always supported that. As far as "why bother": legacy. While we broke people configs a ton of time, this one would be a little hard to port and some widgets, such as radical bar menus, are very heavy compared to a textbox. The overhead of having 1 copy on each of my 5 screen will be very noticeable when it come to all internal callback those widgets can generate. I would prefer to keep the widget tree linked top->bottom rather than double-linked. > Paint outside of the dedicated region. Well, if you look at other widget toolkits, Qt4 was forbidding that. Because of the same corner case I use it for, Qt5 now allow it. The problem is always the same: * People love shadow, shadow are outside of the widget * Glow * Power line array * grow when mouse::hover * transition animation Those use case cannot be implemented without allowing the widget to write outside of its rect. As it currently "just work" (and because I use it :P ) I would prefer this to be still supported one way or another. This can be done with "region of influence" rect as a second return value or something. There is a ton of ways to support it better than it currently is. If we want to get someday serious about animation (I do!). This is required. > How? Well, other toolkit use damaged area and hierarchical structures, so I guess you are going the right way. Rather than flagging the widget itself, I would flag it's container with a list of damaged children. It should mostly "solve" the multiple parent problem without additional logic. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4148 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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 - Vlad Leberstein (owl) -- Thanks for your explanation and sorry for my late response! I've investigated a little bit further and now tend to think that Awesome should really borrow the approach to widget system from popular GUI toolkits. These are the ideas which I came across and have partially implemented(but it's too hackish to show anything right now): 1) Widget's "layout" and "draw" operations are separated i.e. relayout shouldn't be triggered by redraw and vice versa. This enables us to make "draw" method optional. E.g. align's "draw" doesn't really draw anything - it simply recalculates extents of it's children. So when there is no "draw" method in any of the widget's children, we can simpy traverse the tree until child's descendants with draw implemented are found. Moreover, it may be a good idea to separate layout and render hierarchies completely(like geometry managers in TCL/Tk or sizers in WxWidgets) but I can't suggest anything specific right now. 2) Have a "dirty" flag in each widget. I.e. when the widget requests redraw, we determine the path through the widgets hierarchy and set the flag in all the widgets(or at least the ones with "draw" method) on that path. Then drawable performs normal "redraw everything" call but now layouts can make assumptions about what should and what shouldn't be redrawn. As for the corner cases you've outlined, I'm a little bit confused about why one widget can belong to more then one parent? It doesn't bring any additional functionality or save lots of resources, but will complicate the design of widgets hierarchy AFAIU so why bother? Also it doesn't seem quite logical to me that widgets should be allowed to draw outside of their clipping region. I understand the convenience of having such possibility but again, it would significantly complicate partial update mechanics. I imagine that system, where widgets can have multiple unconnected regions is implementable, but AFAIU it would require something like dynamic BVH tree creation to make all unconnected(by widget/layout hierarchy I mean) regions, which occupy the same screen space, automatically redraw themselves when any of them would request redraw. Or the widget hierarchy itself could be reimplemented as a more general graph but I have no idea about how to keep track of z-index of such regions... Anyway, does it really worth it? Am I overlooking something? Also by "a new event loop callback" do you mean an alternative to drawable:refresh()? I performed some very simple tests(not very accurate though) with my current implementation and I believe that coping updated surafce to XCB isn't the real bottleneck, is it? I would greatly appreciate any comments/advices because I don't have much experience in implementing more or less serious GUI systems and will definitely make use of any info provided. Thanks in advance for your help! PS: Sorry for any mistakes - English is not my mother tongue -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4147 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.
[awesome bugs] #1296 - Updated signal causes total relayout
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.
[awesome bugs] #1296 - Updated signal causes total relayout
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Vlad Leberstein (owl) Attached to Project - awesome Summary - Updated signal causes total relayout Task Type - Evolution Request Category - wibox Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Normal Reported Version - 3.5.5 Due in Version - Undecided Due Date - Undecided Details - I would like to implement some animation-heavy widgets but there is a problem. My animation is implemented with the help of "update" signal emitted on timer. Everyting works fine while there are one or two such widgets but when more added, CPU usage grows drastically. The reason is that the "updated" signal causes ALL widgets to redraw themselves and hance do a lot of useless work in most cases. My original intent was to implement separate "redrawn" signal to redraw only the widget which emitted it(and reimplement current layouts like sizers in wxWidget) but I don't see how to do that without breaking current API. Could you recommend something? Thanks in advance! More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296 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.
