The biggest performance bottleneck while resizing is the continous
setting up and tearing down of mmaps and faulting in pages. This commit
introduces a per-window pool that we'll allocate buffers out of if it's
available. Then we set initialize it to a big shm pool when we start
resizing and free it when resizing is done.
There was a lot of code here to do a lot of work we didn't need to do.
If we damage a surface with a shm buffer attached, all we need to do
is to re-upload the damaged region to the texture. As for drm buffers,
we don't assume anything changes on attach and only update the
regions the client tells us to update in the damage request.
On one hand, getopt (in particular the -o suboption syntax) sucks on the
server side, and on the client side we would like to avoid the glib
dependency. We can roll out own option parser and solve both problems
and save a few lines of code total.
We just set the input region to the bounding box of the window frame
and set the opaque region to be the opaque rectangle inside the window
if the child widget is opaque.
The X11 compositor currently posts its key presses as keycode - 8; this
is due to X11 having a historical minimum keycode of 8, whereas evdev is
numbered starting from 1. So while the KEY_* constants begin with
KEY_ESC at 1, the corresponding keycode in both X11 and the XKB keymaps
is 9.
window, on the other hand, was relying on xkb->min_key_code being 8 to
translate its keycodes back to useful values in the XKB 'evdev' keycode
map. min_key_code may not always be 8, for restricted subsets of the
keycode map.
Perhaps not the best solution, but at least consistent.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This change depens on the Wayland core commit:
"protocol: remove absolute coordinates from pointer".
Remove the absolute coordinates from pointer motion and pointer_focus
events.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When window_attach_surface() calls window_get_resize_dx_dy(),
window->resize_edges is cleared. However if there is already a pending
surface to be attached, the resize won't be done until the following
call to window_attach_surface(). In this next call, since resize_edges
is now zero, the top-left corner of the window will be unchanged. If
the user is resizing from the top or left border, this causes the
resize to happen in the wrong direction.
This patch changes window_attach_surface() to call
window_get_resize_dx_dy() only if an attach will actually happen.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The code which sends the button events was checking whether there is a
focus widget with a button handler but then always sending the button
event to the grab widget. If the grab widget is different from the
focus widget at this point then it will check the wrong widget for a
button handler and potentially crash. It is also possible for there to
be no grab widget here in the following situation:
1. Press and hold down the left mouse button
2. Press and hold down the right mouse button
3. Release the left mouse button
4. Release the right mouse button
In this case the grab will be released at step 3 because the code only
keeps track of the grab for one button. Then it will try to send the
release event for the right mouse button to a NULL widget so it will
crash.
Kristian Høgsberg
Jonas Ådahl
Scott Moreau
Rob Clark
Daniel Stone
Pekka Paalanen
Tiago Vignatti
Ander Conselvan de Oliveira
Neil Roberts