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:

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