- Jan 30, 2013
-
-
Owen W. Taylor authored
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.
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
Add META_PROP_VALUE_SYNC_COUNTER_LIST for a property that contains multiple XSyncCounter values. https://bugzilla.gnome.org/show_bug.cgi?id=685463
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
Owen W. Taylor authored
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
-
- Jan 29, 2013
-
-
Kjartan Maraas authored
-
- Jan 21, 2013
-
-
Kjartan Maraas authored
-
- Jan 20, 2013
-
-
Gheyret Kenji authored
Signed-off-by: Gheyret Kenji <gheyret@gmail.com>
-
- Jan 18, 2013
-
-
-
Jasper St. Pierre authored
We have some code in gnome-shell that does the equivalent of: window.get_workspace() == workspace || window.is_on_all_workspaces(); which is a bit unwieldy. We already have a method in mutter, so use that and document it. https://bugzilla.gnome.org/show_bug.cgi?id=691744
-
Jasper St. Pierre authored
With some recent changes to how mask textures are constructed from shapes, a helper method we made was only called in one place, allowing us to drop a reference/destroy, and remove a double clear. https://bugzilla.gnome.org/show_bug.cgi?id=679901
-
-
Jasper St. Pierre authored
While not a massive change by itself, adding new code to use g_clear_pointer without porting existing usage looks strange. https://bugzilla.gnome.org/show_bug.cgi?id=679901
-
- Jan 17, 2013
-
-
Jasper St. Pierre authored
Due to a conditional error, meta_region_builder_add_rectangle was called on every single blank pixel, rather than at the end of spans. With the new rename, it's fairly clear to see the error. Fix the check to ensure that we no longer make extraneous calls to meta_region_builder_add_rectangle. https://bugzilla.gnome.org/show_bug.cgi?id=691874
-
Jasper St. Pierre authored
"w" usually stands for "width", but here it stands for the end X bound, so we'll rename it to the more traditional "x2". https://bugzilla.gnome.org/show_bug.cgi?id=691874
-
Florian Müllner authored
We now rely on XInput being enabled by default, which has only been the case since 1.13.2.
-
- Jan 16, 2013
-
-
-
Nilamdyuti Goswami authored
-
- Jan 15, 2013
-
-
Ihar Hrachyshka authored
-
Daniel Mustieles García authored
-
- Jan 14, 2013
-
-
Florian Müllner authored
Update NEWS.
-
- Jan 13, 2013
-
-
Matej Urbančič authored
-
- Jan 12, 2013
-
-
Alexander Shopov authored
-
- Jan 11, 2013
-
-
Jasper St. Pierre authored
GtkWindow added the BACKGROUND style class to all windows, which the CSS file selects on to set a background color for all windows. Without this, the background color becomes undefined, and thus window frames look like they have "glitchy" graphics. https://bugzilla.gnome.org/show_bug.cgi?id=690317
-
Jasper St. Pierre authored
Commit 5c33b0d7 tried to copy/paste the code that constructed classes, but for some reason didn't copy the theme name. https://bugzilla.gnome.org/show_bug.cgi?id=690317
-
Rui Matos authored
These were there just for consistency's sake.
-
Florian Müllner authored
The minimize action does not make much sense without a window list, which is why its default keybinding was removed in bug 643609; getting the focused window out of the way quickly can still be useful though, so change the description to "Hide window" instead, which does not imply a window list. We will then assign a default shortcut again. https://bugzilla.gnome.org/show_bug.cgi?id=682887
-
- Jan 09, 2013
-
-
-
-
Florian Müllner authored
MetaButtonLayout is extremely unfriendly for introspection: its fields are arrays of a fixed length, but the actual length is determined by a custom stop value (e.g. not NULL / 0). Without API changes this will never work nicely in introspection, but we can at least make it work; start by filling up unused fields with the stop value rather than leaving it at random values. https://bugzilla.gnome.org/show_bug.cgi?id=689263
-