While each stage has at most a GdkFrameClock, the same GdkFrameClock
instance may drive multiple stages per frame. This means that the
mapping between a GdkFrameClock and a ClutterStage is a 1:M one, not a
1:1.
We should store a list of stages associated to each frame clock
instance, so that we can iterate over it when we need to update the
stages.
This commit fixes redraws of applications using multiple stages,
especially when using clutter-gtk.
_cally_actor_get_top_level_origin() uses a compile time check
without runtime check, which will obviously fail when another
backend like wayland is used.
https://bugzilla.gnome.org/show_bug.cgi?id=746575
When multiple relative motion events are received and queued, we can't
base the relative => absolute motion conversion off of the stage pointer
position, since that is only updated when the queue is processed at
the beginning of each frame. The effect of trying to use the stage
pointer position was that subsequent motion events were effectively
dropped.
To improve things, switch to keeping track of the pointer position
ourselves in the evdev backend and adding to that.
This has the side effect of making the internal function
_clutter_input_device_set_coords not effect the internal coordinate
state of the evdev stage, but AFAICS there is nothing depending on that
so that should be fine.
https://bugzilla.gnome.org/show_bug.cgi?id=746328
When a client wants to start initialized it my set the maximized state
before having attached any buffers. Before we'd not notify the client of
the new expected size if the previous size was 0x0 as it would normally
mean we'd resize to 1x1, but since this is not always the case, only
avoid notifying the client if the previous size was 0x0 and the result
is 1x1.
https://bugzilla.gnome.org/show_bug.cgi?id=745303
As we opt out of GTK+/Clutter's HiDPI handling, we need to apply the
window scaling factor manually to decorations, both the geometry and
when drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=744354
There's no point in trying to go ahead if we don't have a context to
create the CoglOnscreen framebuffer, and Cogl will crash anyway if we
pass NULL to the constructor.
If the wl_surface resource happens to be destroyed before any other
role resource, the destructor for the latter will attempt to
access/modify random memory.
Fix this by ensuring the associated resources are destroyed on the
wl_surface destructor, this will free all associated memory and
remove the resources ahead of their imminent destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=745734
In 3.16, GDM keeps a login screen running on vt1.
This login screen starts an Xwayland instance.
Since it's the first X server to start, it gets
the prized :0 display number.
This commit works around that problem, for now,
by having GDM's display number start at 1024.
https://bugzilla.gnome.org/show_bug.cgi?id=746295
With server-side buffer allocation, buffers may be returned out of order
(e.g. they may be held onto by external references or hardware). As such
we may see older buffers the frame after we discard the history from
seeing a very young buffer. To overcome this we want to keep the history
in a ring so we can keep track of older entries without keeping an
unbounded list. After converting to a ring, the maximum buffer age
observed during testing was 5 (expected value of 4), but before we could
see ages as high as 9 due to the huge latency spikes caused by doing full
buffer redraws (compounded by external listeners doing readback on the
damaged areas, for example vnc, drm/udl, prime). For this reason, a
maximum age of 16 was chosen to be suitably large enough to prevent these
worst cases from taxing the system.
v2: Fix off-by-one in combining the damage histroy into the clipping
rectangle, and apply copious whitespace fixes.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=745512
References: https://bugzilla.gnome.org/show_bug.cgi?id=724788
References: https://bugzilla.gnome.org/show_bug.cgi?id=669122
cogl provides an interface to pass along damage with the swap buffers
request. This is useful for the display servers and hardware to minimise
the work done in updating the screen and also reducing the work done by
external listeners (such as vnc, drm/udl and PRIME).
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=745512
If the rectangle is allocate a size smaller than the border, drawing the
border will end up with negative coordinates, and will mess up the whole
thing. Since rectangles don't have a minimum preferred size, we cannot
rely on the allocation being big enough to contain the border and the
background color.
If the rectangle is smaller than the border width value, we just paint
the border color as well.
With all input events being handled through clutter, this only confuses
things, and most nominally, coerces touch events through places we didn't
intend to, like the window frame.
This makes again all touch events only handled in the passive grab on X11,
while the rest stays pointer (emulated) only.
https://bugzilla.gnome.org/show_bug.cgi?id=745335
On startup, the cursor is kept hidden if there's any touchscreen available.
If the device that was last interacted is removed, we check on available
pointing devices though, so we don't possibly hide the pointer if there are
further mice/touchpads/etc.
Devices being added don't update cursor visibility, we wait for the user
interacting with those instead.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
On X11, calling this function on meta_display_handle_events() will not catch
mouse events happening over clients, so poke directly in the backend for
XI_DeviceChanged events, which mutter will get on device switches.
The code has been slightly refactored so we deal with XIEvents at a single
handle_input_event() function.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
This function can be used to trigger changes depending on the device type
that is currently emitting the events. So far, it is used to switch cursor
visibility on/off on touchscreen interaction.
A "last-device-updated" signal has also been added, in order allow hooking
other behavior changes (eg. OSK) when the last device changes.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
Since commit 6e06648f7, we start out with the invisible frame parts
only, and then add the unconstrained rect's height (which consists of
the visible parts of both frame and client window) *unless* the window
is shaded. While we indeed don't want to add the client height in that
case, we need to explicitly include the visible frame parts now.
https://bugzilla.gnome.org/show_bug.cgi?id=746145
