The X11 part of the GDK backend takes into account the scaling factor of its
window when resizing the underlying X11 objects. We need to do the same for
Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=755245
This is now stored as platform data in the ClutterEvent, so can
be retrieved with the clutter_evdev_event_get_event_code() call
that's been added to the evdev backend.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
Device managers can now implement the ClutterEventExtender interface
that allows them to set their own data to events, make the backend call
those implementations if the device manager implements the interface.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
This normally belonged to the ClutterBackend, however there's device
managers (eg. evdev) that are somewhat detached from the backend, so
need to bridge this somehow.
This allows device managers to implement these bits that were usually
responsibility of the ClutterBackend.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
On X11 those were skipped, so additional pointer buttons would come up
as button >= 8 events. Do here the same, so we remain compatible across
backends.
https://bugzilla.gnome.org/show_bug.cgi?id=758237
There's handlers around relying on up/down/left/right scroll events,
which won't work as expected if only smooth scroll events are sent.
In order to work properly there, we have to retrofit discrete scroll
events on the evdev backend.
Fix this by implementing emission (on devices with a wheel) and
emulation (on anything else) of discrete scroll events. On the former
both smooth and discrete events are set, for the latter we do accumulate
the dx/dy of the latest scroll events, and emit discrete ones when we
accumulated enough. The ending 0/0 event will reset the accumulators for
the next scrolling batch.
https://bugzilla.gnome.org/show_bug.cgi?id=756284
When enable_paint_unmapped is disabled, we shouldn't force the
source widget to be unmapped if the constraints would keep it
mapped; in practice this shouldn't matter unless a paint handler
is messing with the map state.
https://bugzilla.gnome.org/show_bug.cgi?id=745517
Enable animation updates from the GdkFrameClock whenever any timeline is
added to the ClutterMasterClockGdk. This may improve animation
smoothness (depending on the GDK backend in use) because it allows GDK
to tweak its frame timing for animation purposes.
https://bugzilla.gnome.org/show_bug.cgi?id=755357
This is how GdkFrameClock is meant to be used: the frame time is meant
to be queried from the GdkFrameClock within its frame signals, rather
from the system monotonic time source.
https://bugzilla.gnome.org/show_bug.cgi?id=755357
When removing the frame callback on the CoglOnscreen, we loose the ability
to get notified of swap events. This could leave us with a counter != 0
which leads to a deadlock situation after the next realize/draw cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=755014
If we call _clutter_stage_do_update() on a ClutterStage that isn't
mapped/visible, no GL command will be queued, and the Mesa/DRI2
implementation of SwapBuffers will do nothing. This causes
GLX_INTEL_swap_event to not be emitted by the X server because no swapping
has been requested through DRI2 and it eventually leads to a deadlock
situation in ClutterStageCogl because we're waiting for an event before we
start the next draw cycle.
This patch removes the non mapped stages from the list of stages to process.
This is consistent with a previous patch for the ClutterMasterClockGdk [1].
[1] : 5733ad58e5https://bugzilla.gnome.org/show_bug.cgi?id=755014
Setting up the sync_to_vblank in the MasterClock is a bit too late as
the MasterClock can be created after a StageWindow has been created
and realized (and therefore all of its Cogl/GL state setup already).
So move the setup to the backend, prior to any StageWindow creation.
https://bugzilla.gnome.org/show_bug.cgi?id=754938
