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
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
New experimental API is added to allow changing the way that redraws
are timed for a stage to include a "sync delay" - a period after
the vertical blanking period where Clutter simply waits for updates.
In detail, the algorithm is that when the master clock is restarted
after drawing a frame (in the case where there are timelines running)
or started fresh in response to a queued redraw or relayout, the
start is scheduled at the next sync point (sync_delay ms after the
predicted vblank period) rather than done immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=692901
When Cogl is compiled with support for both the GL and GLES drivers it
only includes the GL header and not the GLES header. That means in
that case it would not compile in the code for the
GL_EXT_discard_framebuffer extension even though it could be used on
the GLES driver. This patch makes it use the standard names for the
GL_COLOR, GL_STENCIL etc names instead of the _EXT suffixed names and
manually defines them if we are using the GLES headers. That way the
discard code can be used unconditionally.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 59c30292d0f3c28d6e0e08bc5bf3b4b10545d856)
This patch just adds a call to _cogl_framebuffer_flush_state to ensure
the correct framebuffer is bound before discarding its buffers.
Previously it would presumably just discard the buffers of whatever
framebuffer happened to be used last.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 37c390a5b33d4f65ff6c834e9be2f8de716635ee)
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
- 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
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
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
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
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
The GLES2 spec only guarantees calling glReadPixels with GL_RGBA and
an implementation specific format. Mesa seems to now reject reading
with GL_RGB so the test had started failing. This fixes it to just
read using GL_RGBA.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 745cbcbdee0f5b4df4c6a735b03709248a551884)
test_utils_compare_pixel makes the error report slightly easier to
read because it displays the values for the whole pixel instead of
reporting that there was a difference somewhere.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit a094ac9688a5e6b53be1cd379dc045973aab2fae)
The array allocated for storing the difference flags for each layer in
cogl-pipeline-opengl.c was being cleared with the size of a pointer
instead of the size actually allocated for the array. Presumably this
would mean that if there is more than one layer it wouldn't clear the
array properly.
Also the size of the array was slightly wrong because it was allocating
the size of a pointer for each layer instead of the size of an
unsigned long.
This was originally reported by Jasper St. Pierre on #clutter.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 1e134dd7cd5317651be158a483c7cb2723ce8869)
In commit 8f4e39b6d716 the Wayland code was updated to use the new
xkbcommon API. This involved changing the common XKB code shared with
the evdev input backend. However the evdev input backend was not
modified so it wouldn't compile. This patch just makes a minor change
to update it.
https://bugzilla.gnome.org/show_bug.cgi?id=693348
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
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
Use the buffer_age extension when available to recycle backbuffer contents
instead of blitting from the back to front buffer when doing clipped redraws.
The picking is now done in a pixel that is going to be repaired during the next
redraw cycle for non static scences.
This should improve performance and avoid tearing.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=669122
This allows us to report to the backend that the stage's back buffer has been trashed
while handling picking. If the backend is keeping track of the contents of back buffers
so it can minimize how much of the stage is redrawn then it needs to know when we do pick
renders so it can invalidate the back buffer.
Based on patch from Robert Bragg <robert@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=669122
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
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
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
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
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
