[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)

2015-01-11 Thread awesome
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=detailstask_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)

2015-01-11 Thread awesome
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=detailstask_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)

2014-12-06 Thread awesome
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=detailstask_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

2014-10-14 Thread awesome
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=detailstask_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

2014-10-14 Thread awesome
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=detailstask_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

2014-10-14 Thread awesome
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=detailstask_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

2014-10-14 Thread awesome
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=detailstask_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

2014-10-13 Thread awesome
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=detailstask_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

2014-10-13 Thread awesome
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=detailstask_id=1218project=1order=idsort=descpagenum=3
--

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=detailstask_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 (Attachment added)

2014-10-05 Thread awesome
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=detailstask_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

2014-10-05 Thread awesome
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=detailstask_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)

2014-10-05 Thread awesome
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=detailstask_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 (Attachment added)

2014-10-05 Thread awesome
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=detailstask_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

2014-10-04 Thread awesome
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=detailstask_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

2014-10-04 Thread awesome
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=detailstask_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 (Attachment added)

2014-10-04 Thread awesome
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=detailstask_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

2014-10-04 Thread awesome
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=detailstask_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

2014-10-04 Thread awesome
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=detailstask_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

2014-10-02 Thread awesome
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=detailstask_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

2014-10-02 Thread awesome
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=detailstask_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

2014-09-05 Thread awesome
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=detailstask_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.


[awesome bugs] #1296 - Updated signal causes total relayout

2014-09-05 Thread awesome
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.