Commit Graph

5570 Commits

Author SHA1 Message Date
Owen W. Taylor
995e8040dd Bump Clutter and Cogl version requirements
Cogl - require 1.13.3 for CoglFrameInfo
Clutter - require 1.13.5 for clutter_stage_set_sync_delay()
2013-02-13 09:48:27 -05:00
Owen W. Taylor
0503f6bb9a Consistently use meta_grab_op_is_resizing() for _NET_WM_SYNC_REQUEST
In different places we checked the grab op differently when determing
whether we are using _NET_WM_SYNC_REQUEST. This was somewhat covered
up previously by the fact that we only had a sync alarm when using
_NET_WM_SYNC_REQUEST, but that is no longer the case, so consistently
use meta_grab_op_is_resizing() everywhere.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
87fe9685b5 Distinguish "no delay" frames from spontaneous drawing
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.

Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:

 - Increment by 1: a no-delay frame
 - Increment by more than 1: a non-urgent frame, handle normally

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
2d9b8bb2d0 Send _NET_WM_FRAME_TIMINGS messages
We previously had timestamp information stubbed out in
_NET_WM_FRAME_DRAWN. Instead of this, add a high-resolution timestamp
in _NET_WM_FRAME_DRAWN then send a _NET_WM_FRAME_TIMINGS message
after when we have complete frame timing information, representing
the "presentation time" of the frame as an offset from the timestamp
in _NET_WM_FRAME_DRAWN.

To provide maximum space in the messages,_NET_WM_FRAME_DRAWN and
_NET_WM_FRAME_TIMINGS are not done as WM_PROTOCOLS messages but
have their own message types.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
74b1a9e2b9 Add meta_compositor_monotonic_time_to_server_time()
Add a function to convert from g_get_monotonic_time() to a
"high-resolution server timestamp" with microsecond precision.
These timestamps will be used when communicating frame timing
information to the client.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
fcc178ee8c Use XSyncSetPriority()
Use XSyncSetPriority() to prioritize the compositor above applications
for X server priority. In practice, this makes little difference because
the Xorg "smart scheduler" will schedule in a single application for
time slices that exceed the frame drawing time, but it's theoretically
right and might make a difference if the X server scheduler is improved.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
d8696c17be Use clutter_stage_set_sync_delay()
Using a "sync delay" where we wait for 2 ms after the vblank before
starting to draw the next frame provides for much more predictable
latency for applications. An application can know that if it completes
a frame any time between 8ms before the vblank to the vblank,
it will reliably be drawn on the following vblank period, rather than
having an unpredictable latency depending on whether the compositor
is currently busy drawing a frame or not.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
b07aea467e Enable CLUTTER / COGL_ENABLE_EXPERIMENTAL_API globally
Instead of defining CLUTTER_ENABLE_EXPERIMENTAL_API and
COGL_ENABLE_EXPERIMENTAL_API in individual source files, enable
them on the command line. We weren't tracking exactly what pieces of
experimental API we were using and we were using the experimental
API in most source files that used Clutter and Cogl, so the
local #defines were annoying rather than useful.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
04ef448927 Handle _NET_WM_SYNC_REQUEST_COUNTER updates without redraw
It's possible that a client might update the (extended)
_NET_WM_SYNC_REQUEST_COUNTER counter twice without actually drawing
anything. In that case, we still should send a _NET_WM_FRAME_DRAWN
message since it's hard for a client to know every case in which
no damage is generated. For now, do it the easy way by forcing a
stage repaint.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
790bfcad9a MetaWindow: always resize the frame first when we have synchronization
Resizing the frame triggers creation of a new backing pixmap for the
window, so we should do that first before we resize the client window
and mess up the contents of the old backing pixmap.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
fbfab93c63 Send _NET_WM_FRAME_DRAWN messages
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
70c0d39fa7 Add support for an extended style of _NET_WM_SYNC_REQUEST_COUNTER
If an application provides two values in _NET_WM_SYNC_REQUEST_COUNTER,
use that as a signal that the applications wants an extended behavior
where it can update the counter as well as the window manager. If the
application updates the counter to an odd value, updates of the
window are frozen until the counter is updated again to an even value.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
7d43bde019 Support properties with lists of XSyncCounter
Add META_PROP_VALUE_SYNC_COUNTER_LIST for a property that contains
multiple XSyncCounter values.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
7743c70d47 Move sync alarms to be per-window and permanent
Instead of creating a new alarm each time we resize a window
interactively, create an alarm the first time we resize a window
and keep it around permanently until we unmanage the window.
Doing it this way will be useful when we allow the application to
spontaneously generate sync request updates to indicate
frames it is drawing.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:25 -05:00
Owen W. Taylor
c9343e3ee3 Implement freezing of updates during resize
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:40:07 -05:00
Owen W. Taylor
3abaf506a6 MetaWindowActor: Use guint for bitfields
A 1-bit boolean (int) bitfield has the values 0 and -1. Use
guint instead for bitfield values.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:39:09 -05:00
A S Alam
9de142db09 Punjabi: Translation updated (aalam) 2013-02-10 23:36:40 +00:00
Adel Gadllah
2942b22ccf screen: Don't try to move / resize OR windows on montior change
meta_screen_resize calls meta_window_update_for_monitors_changed for all
windows including OR windows when the monitors change (or screen size).

This calls meta_window_move_between_rects for the window which attempts to
move the OR window by calling meta_window_move_resize.

meta_window_move_resize refuses to do anything on OR windows (just returns
for OR windows).

This causes a storm of assert messages when the screen
resolution changes while an OR window is visible.
(like the one gnome-control-center displays with the monitor name).

Fix that by not calling meta_window_update_for_monitors_changed for OR windows
and let the applications handle them by themselves.

https://bugzilla.gnome.org/show_bug.cgi?id=693540
2013-02-10 20:43:03 +01:00
Cosimo Cecchi
94e6e55ef7 resize-popup: use a tooltip style for the resize popup window
- set GTK_STYLE_CLASS_TOOLTIP on the window, and use the same code of
  GtkTooltip to paint it
- set GDK_WINDOW_TYPE_HINT_TOOLTIP and make the window non-resizable, so
  it doesn't get an incorrect shadow from the WM

https://bugzilla.gnome.org/show_bug.cgi?id=692741
2013-02-10 14:25:27 -05:00
Cosimo Cecchi
34fc234fd7 resize-popup: set a bigger margin
Since we're going to use the tooltip's rounded corners we need a little
bit more of margin (which wasn't a bad idea even with the frame).
Also, don't use GtkMisc for this anymore.

https://bugzilla.gnome.org/show_bug.cgi?id=692741
2013-02-10 14:25:27 -05:00
Cosimo Cecchi
c3ffd28bb6 resize-popup: don't use a GtkFrame
We want this to look like a normal tooltip - start with removing the
GtkFrame around its shape.

https://bugzilla.gnome.org/show_bug.cgi?id=692741
2013-02-10 14:25:27 -05:00
Adel Gadllah
1c680be11a meta-window-actor: Make sure that the shape_region is always set
Start off with an empty region to make sure that the shape_region is
always set even for unredirected and frozen windows.

https://bugzilla.gnome.org/show_bug.cgi?id=693482
2013-02-09 20:56:03 +01:00
Adel Gadllah
a362c08f4e Fix build error introduced by d482590c84 2013-02-09 17:02:36 +01:00
Rui Matos
380154af0a screen: Fix a potentially endless loop
We always need to move the list pointer forward.

https://bugzilla.gnome.org/show_bug.cgi?id=693475
2013-02-09 16:07:59 +01:00
Adel Gadllah
d482590c84 Fix button check in meta_window_client_message
Fixes a regression introduced in 3a3be74e37

https://bugzilla.gnome.org/show_bug.cgi?id=692718
2013-02-09 13:17:42 +01:00
Tim Lunn
b3c572b8e3 barrier: fix fallback for unsupported servers
add missing ifdef HAVE_XI23.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-09 11:27:22 +11:00
Jasper St. Pierre
c64eb94724 display: Remove an unused code path for enabling the compositor 2013-02-08 14:36:20 -05:00
Jasper St. Pierre
d8f569eaf5 display: Rename window_ids to xids
As the hash table no longer stores only window IDs, we should rename it so
that we make sure to check if something is actually a window before using it
as a window.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-08 14:23:38 -05:00
Jasper St. Pierre
57c31a56f4 barrier: Add support for new barrier features in XInput 2.3
XInput 2.3 adds support for "barrier events", which let us know when
a pointer barrier has been hit, and when the pointer has stopped
hitting the barrier, and lets us "release" the barrier, temporarily
letting the pointer pass through the barrier. These features can be
combined to allow for certain pointer gestures, such as "pushing"
against the bottom of the screen, or stopping the pointer on monitor
edges while dragging slowly for increased edge precision.

This commit should allow graceful fallback if servers with
XInput 2.3 aren't supported.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-08 14:23:38 -05:00
Jasper St. Pierre
8b21df92f0 barrier: Add a new Meta wrapper for pointer barriers
Currently, we have a few function wrappers in the shell for pointer
barriers. If we want to implement interactive features on barriers,
we need some sort of signal to be notified of the interactivity.
In that case, we need to make a more sophisticated object-based wrapper
for a pointer barrier. Add one, and stick it in mutter.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-08 14:23:38 -05:00
Florian Müllner
e914595062 theme-viewer: Stop using deprecated GTK+ functions
https://bugzilla.gnome.org/show_bug.cgi?id=693439
2013-02-08 19:08:55 +01:00
Adel Gadllah
a2a3188331 Fix compiler warnings 2013-02-08 00:22:54 +01:00
Jasper St. Pierre
453020c315 Make sure to include the old XI2 mask when selecting for events
Some windows may already have event masks on them that we've selected
for, especially if we're using GTK+ windows. In particular, this fixes
window menus in the XI2 port.

https://bugzilla.gnome.org/show_bug.cgi?id=690581
2013-02-07 18:13:40 -05:00
Jasper St. Pierre
d794db876a core: Add a helper function to grab the old event mask of a window
https://bugzilla.gnome.org/show_bug.cgi?id=690581
2013-02-07 17:53:53 -05:00
Adel Gadllah
b33b4a8e2c ui: Don't use gdk_device_manager_get_client_pointer
gdk_device_manager_get_client_pointer which in calls
XIGetClientPointer seems to be very slow in a XI2 world.

So use
	gdk_x11_device_manager_lookup (gmanager, META_VIRTUAL_CORE_POINTER_ID)
instead.

https://bugzilla.gnome.org/show_bug.cgi?id=693354
2013-02-07 21:54:27 +01:00
Fran Diéguez
6f74a63bbd Updated Galician translations 2013-02-07 00:52:12 +01:00
Adel Gadllah
5298d1c8d0 meta-window-actor: Don't do check_needs_reshape when not mapped
This can cause us ending up with a wrong mask because we don't yet
have a pixmap to use in build_and_scan_frame_mask().

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 18:11:36 +01:00
Rico Tzschichholz
493f619adc meta-window-actor: Fix uninitialized variable
Fallout of 90f2a3ae4c
2013-02-06 08:19:20 +01:00
Jasper St. Pierre
a613a55658 Support _NET_WM_OPAQUE_REGION
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 00:08:04 -05:00
Jasper St. Pierre
3fe5a676c2 window-actor: Remove the bounding region
With the shape region always set, it turns out the bounding region
is only used in one place, that's easily replaced with a variable
we already have available to us.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 00:05:23 -05:00
Jasper St. Pierre
19420f147f window-actor: Remove conditional checks for the shape region
With recent changes in the way the window mask texture is constructed,
the shape_region is always set, which means that we can remove
conditionals checking if the shape region is set.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 00:05:23 -05:00
Jasper St. Pierre
32b7743735 screen: Add an introspectible wrapper for find_monitor_for_rect
Instead of returning a MonitorInfo, it returns a monitor index.

https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-06 00:04:15 -05:00
Jasper St. Pierre
093e101252 Make work_area calculation funcs public and introspectible
https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-06 00:03:47 -05:00
Jasper St. Pierre
6f873be7fa Revert "Make work_area calculation funcs public and introspectible"
This reverts commit d8058138ab.
2013-02-06 00:03:10 -05:00
Jasper St. Pierre
f37dd25e92 Revert "screen: Add an introspectible wrapper for find_monitor_for_rect"
This reverts commit 3900aa10f8.
2013-02-06 00:02:04 -05:00
Jasper St. Pierre
d48df249c9 Revert "window-actor: Ensure we always have a valid shape_region"
This reverts commit 07273a075d.
2013-02-06 00:02:03 -05:00
Jasper St. Pierre
e48c3dac87 Revert "window-actor: Remove conditional checks for the shape region"
This reverts commit 84930f1d78.
2013-02-06 00:02:02 -05:00
Jasper St. Pierre
3516902fae Revert "window-actor: Remove the bounding region"
This reverts commit 66185a468c.
2013-02-06 00:02:00 -05:00
Jasper St. Pierre
66185a468c window-actor: Remove the bounding region
With the shape region always set, it turns out the bounding region
is only used in one place, that's easily replaced with a variable
we already have available to us.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-05 23:59:20 -05:00
Jasper St. Pierre
84930f1d78 window-actor: Remove conditional checks for the shape region
With recent changes in the way the window mask texture is constructed,
the shape_region is always set, which means that we can remove
conditionals checking if the shape region is set.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-05 23:54:13 -05:00