Window menus use the first key combination for a binding to show the
acceleration, so the list must be in the right configured order, which
is the opposite of what's built by g_slist_prepend()
https://bugzilla.gnome.org/show_bug.cgi?id=694045
Now that the background actor is reactive, this means that
clicks on the window group part of the stage, even when they're
on an X window, will be registered as the background actor, as
all of the other children of the group aren't reactive. This can
happen when a plugin takes a modal grab, for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=681540
The guard window is effectively the background window, as it sits
in between live windows and minimized windows. This gives us a nice
easy place to allow users to allow users to right-click or long-press
on the wallpaper.
https://bugzilla.gnome.org/show_bug.cgi?id=681540
We do, in fact, need freezing to affect window geometry, so that
move-resize operations (such as an interactive resize from the
left, or a resize of a popup centered by the application) occur
atomically.
So to make map effects work properly, only exclude the initial
placement of a window from freezing. (In the future, we may want
to consider whether pure moves of a window being done in response
to a user drag should also be excluded from freezing.)
Rename meta_window_sync_actor_position() to
meta_window_sync_actor_geometry() for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
If a window is frozen because it is repainting, that shouldn't kee[p
us from updating its position: we don't want a slow-to-update window
to move around the screen chunkily when dragged. (This does reduce
the efficiency of begin/end frames for replacing double-buffering,
but that never works very well in the case where there was an overlapping
window or the entire screen needed redrawing for whatever reason.)
This fixes a bug where a window that was mapped frozen would not get
positioned properly until after the map effect finished, and would
jump from 0,0 at that point. Since effects *do* need to prevent
actor repositioning by Mutter, we must position the actor before any
effect starts.
Because we now are queuing invalidates on frozen windows, fix the
logic for that so that we properly update everything when the window
unfreezes.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
For the boolean environment variables that affect the running of the
conformance tests we now explicitly check the value of those variables
so that "0", "off" and "false" (upper or lower case) will be considered
as FALSE instead of just interpreting set as TRUE and unset as FALSE. If
the value is set to something entirely spurious then we abort with a
warning message. Thanks to Artie Eoff for suggesting this change.
https://bugzilla.gnome.org/show_bug.cgi?id=693894
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 25a8cf3607a482ca390eb9841295d1b365cbe53b)
This updates the examples and test-journal which now use the _FRAME_SYNC
events to throttle rendering so that they don't install a redundant idle
handler to paint when they get a FRAME_SYNC event and instead they now
directly paint when the event is received.
(cherry picked from commit 579eb75e6ac6f50d7a9cfe5093435126158b3c96)
This lists the cogl_onscreen_add/remove_frame_callback functions and
CoglFrameClosure and CoglFrameCallback types in cogl2-sections.txt
(cherry picked from commit 6655fee97fb6bcc2a516b710cc8ca1179685cb8f)
This updates cogl-gles2-gears to use the new
cogl_onscreen_add_frame_callback() api to use _SYNC events for
throttling.
(cherry picked from commit 4fdb8b966ad3501842bbdff3d96b0c4e098e2646)
This updates cogl-gles2-context to use the new
cogl_onscreen_add_frame_callback() api to use _SYNC events for
throttling.
(cherry picked from commit 2063306645e32ceb3252ebcd2eebd33c879d7fbe)
This updates test-journal to use the new
cogl_onscreen_add_frame_callback() api to use _SYNC events for
throttling.
(cherry picked from commit 24e6a5376ed3982f5647e2c2df0618272c381636)
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
During resizing, An odd counter value (indicating the beginning of a frame)
shouldn't cause us to redraw and start a new frame, only an even counter
value. This was causing the frozen state for the window frame counter to
overlap the frozen state for the resize, causing the window not to be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
Put override redirect windows such as menus into a separate window group
stacked above everything else. This will allow us to visually put these
above other compositior chrome.
Based on a patch from Muffin.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
If we make this per-context and create two Cogl contexts, some types
won't re-register, and we'll be in a broken state where some types will
be considered not to be texture types.
https://bugzilla.gnome.org/show_bug.cgi?id=693696
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 567f049d20554bb8ea4e40fa5e72a9fd0bbd409e)
If anything in the system changes the config for fontconfig then an
XSetting will be set to record the last timestamp of the config file.
This is presumably so that applications can be notified that it has
changed and can reload the configuration. However once this setting is
set it will remain set for the lifetime of the X server. This causes
Clutter to handle the setting during the initialisation of the
backend. Previously this would cause problems because Clutter would
end up creating the default PangoFontMap before the backend has
created the CoglContext. The PangoFontMap would in turn cause the
default CoglContext to be created. Clutter will then later create its
own CoglContext which means there will be two and the first one will
be leaked. Cogl currently can't really cope with multiple contexts
being created so it falls apart.
This patch fixes it to skip reloading the config for fontconfig if
there isn't a default font map yet. The config will presumably
naturally be read with the latest values when it is finally created
anyway so it doesn't need to be read immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=693696
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
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
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
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
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
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
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
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
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
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
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
