I was creating 2000 wiboxes in a loop (don't ask) and creating them took
forever. According to callgrind, there were about 2 million calls to
xcb_configure_window() and most (if not all) of them were from client_stack().
Awesome spent 70% of its cpu time in these client_stack() calls.
client_stack() is O(N^2) on the number of clients (it walks the list of clients
itself twice and each call to client_stack_above() walks the list too) and O(N)
on the number of wiboxes (it walks the wibox list twice). So obviously calls to
it should be rare.
This patch makes client_stack() only set a flag which is later checked. This
should reduce the number of restacks to the bare minimum. With this patch,
neither xcb_configure_window() nor anything else client_stack() related shows
up as having a lot of calls or using much cpu time.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
- We are tracking focus, using FocusIn/FocusOut events handlers, so user
should never be confused about which client has focus
- window_setfocus function generates focus change requests to the X server
- client_focus uses window_setfocus to set input focus
- revert_to when setting input focus set to Parent, compliant with
ICCCM convention ([1])
- DEBUG flag for those who want to debug focus handlers
Most of the changes, are compliant with X11 handbook ([0]), but some
where obtained experimentally.
Kudos to Maarten Maathuis who helped a lot with this.
[0]
http://cgit.freedesktop.org/xorg/doc/xorg-docs/plain/hardcopy/X11/xlib.PS.gz
[1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.7
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Mariusz Ceier <mceier@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
- WINDOW_TYPE_DOCK are chosen first.
- Top/Bottom take precedence over Left/Right.
- Struts are automatically updated.
- Automatically avoid overlap with other struts or wibox'es.
Signed-off-by: Julien Danjou <julien@danjou.info>
Version 1 was supposed to store somehow the mouse coordinates to drop
spurious EnterNotify.
Now, we use a simpler way: we just tell the X server we do not want to
receive this events while we are arranging, since we would get spurious
ones.
Signed-off-by: Julien Danjou <julien@danjou.info>
with small fixes, changes:
- client_focus handles case when c==NULL
- don't focus on already focused client
- added window_takefocus function, that sends WM_TAKE_FOCUS client
message. It is needed by GAIM and Locally Active Input Model.
- moved invocation of lua focus hook from client_focus to
client_focus_hook function.
- client_focus has one additional paremeter, sendmessage.
It is used in FocusIn event handler, to disable sending SetInputFocus
and WM_TAKE_FOCUS messages ( to avoid infinite loop )
Signed-off-by: Mariusz Ceier <mceier@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
According to EWMH, the window manager is responsible for removing the
urgent state of a client. Also, this commit adds a new
client_seturgent(client_t *, bool) function to set the urgent state if
needed.
Signed-off-by: Julien Danjou <julien@danjou.info>
here is a little patch which fix the unresizeable window bug. This bug is due
to some windows, like firefox, having XCB_SIZE_HINT_P_MAX_SIZE and
XCB_SIZE_HINT_P_MIN_SIZE on and all related values to 0, which makes
client_isfixed believe that the windows are of fixed size.
Hope this is the right way to fix it. Anyway now you know where this bug comes
from.
Signed-off-by: Julien Danjou <julien@danjou.info>
- From now on clients shall remain mapped for their entire lifetime.
- This should seriously boost tag switching speed with composite active.
- A lesser improvement may be noticed in non-composite situations.
- Titlebars that are set to invisble are still unmapped.
Since it would clutter the implementation and titlebars are cheap to render.
Not to mention that invisible titlebars are pretty rare.
- It's safe to attach titlebars while the client is banned.
- Titlebars are explicitly removed at exit.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
The patch is mainly to export client_array_t object to Lua,
but can be used to export any ..._array_t object.
The idea: export to Lua not a table, but userdata with
metamethods to get/set/define length of ..._array_t object
directly.
Now when I get clients field from tag object C code
creates full copy of client_array_t structure into Lua table.
It takes traversing a whole array of data.
I did it in other way: userdata is exported, with __index,
__newindex, and __len meta-methods defined, and Lua
script gains direct access to client_array_t C-array:
it can get client object, get length of array and assign
client objects to some index in C-array.
Pros:
No overhead of creation a copy of C-structure into Lua-table:
if I want just to test a number of clients for a tag, I don't need
a whole loop to build table, I just want to read clients->len field,
and I do so via __len meta-method.
Also if I want to get some client from tags.clients, I don't need
to create ALL clients Lua-objects, I just get client_t C-struct
and create Lua-object from it. Just in place.
So Lua-loop enuming all tag.clients is not 2 loops internally
(first create copy of tag.clients into Lua-table, then enum this table),
but only one, and if I break out of loop in the middle, I create
only some client Lua-objects, not all of them from tag.clients.
Contras:
As far as clients field is not a table, I cant use pairs/ipairs
and other table functions for it.
But it can be implemented in other way:
for k,c pairs(tag.clients) => for k = 1, #tag.clients,
table.insert(tag.clients, client) => tag.clients[#tag.clients+1] = client
etc.
One more Pro now:
As far as tag.clients in current implementation returns copy of data
table.insert doesn't do what's expected: it doesn't really add client
into tag.clients "array".
With my implementation client is added as expected, as we work with
client_array_t structure directly.
Signed-off-by: Julien Danjou <julien@danjou.info>