The model API was an ad hoc addition to Clutter, back in the 0.6 days,
that was needed because GLib did not offer anything of sort, and the
only model-like storage was inside GTK+. The API design was heavily
based on GtkTreeModel and friends, with column-based collections of
generic data.
Since then, the model API inside Clutter has not really been integrated
in the core API; on the other hand, GIO has grown a model API, and it's
seeing more use in the platform.
This means that the ClutterModel API should finally be deprecated, and
we should move code to the GListModel API inside GIO.
Certain crossing modes notify about synthesized events, where
the pointer didn't really leave the window. Unsetting the stage
from the device at that time is incorrect, and will leave all
remaining touches unable to pick coordinates, so silently eaten
away.
https://bugzilla.gnome.org/show_bug.cgi?id=750496
Straight from Cogl.
This allows us to propagate the GdkVisual Cogl and Clutter use to
embedding toolkits, like GTK+.
The function is annotated as being added to the 1.22 development
cycle because it will be backported to the stable branch, so that
downstream developers can package up a version of Clutter that does
not crash on nVidia.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
GDK 3.16 started selecting different visuals, to best comply with the
requirements for OpenGL, and this has broken Clutter on GLX drivers that
are fairly picky in how they select visuals and GLXFBConfig.
GDK selects GLXFBConfig that do not include depth or stencil buffers;
Cogl, on the other hand, needs both depth and stencil buffers, and keeps
selecting the first available visual, assuming that the GLX driver will
give us the best compliant one, as per specification. Sadly, some
drivers will return incompatible configurations, and then bomb out when
you try to embed Clutter inside GTK+, because of mismatched visuals.
Cogl has an old, deprecated, Clutter-only API that allows us to retrieve
the XVisualInfo mapping to the GLXFBConfig it uses; this means we should
look up the GdkVisual for it when creating our own GdkWindows, instead
of relying on the RGBA and system GdkVisuals exposed by GDK — at least
on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=747489
In order to do device matching we need to propagate more information,
like the device_id (only on X11 with the XInput2 extension enabled),
the vendor id, and the product id.
https://bugzilla.gnome.org/show_bug.cgi?id=747951
When defining clutter_stage_gdk_update_foreign_event_mask, check for the
same macros as when actually using it.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Its ::gesture-end implementation used to check the press/release
coordinates for the first touchpoint. On multifinger swipes, we
can receive this vfunc called due to other touch sequence going
first, so we'd get 0/0 as the release coordinates for this still
active sequence, resulting in bogus directions.
Instead, check the last event coordinates, that will be always
correct regardless of whether the touchpoint 0 finished yet or
not.
https://bugzilla.gnome.org/show_bug.cgi?id=749739
Commit 79849ef1d5fff9acd310cd68d59df0c7cf2cb28f had a typo in the
device property format check. This property is formated in 8-bit
items, not 32-bit.
This went unnoticed till now because some touchpads were still being
detected as such due to a second check below:
else if (strstr (name, "touchpad") != NULL)
source = CLUTTER_TOUCHPAD_DEVICE;
https://bugzilla.gnome.org/show_bug.cgi?id=749482
It could happen that gdk_screen_get_setting fails to retreive
Gdk/WindowScalingFactor which leads to the following warnings when
clutter_init is called:
GLib-GObject-WARNING **: value "0" of type 'gint' is invalid or out of range for property 'window-scaling-factor' of type 'gint'
GLib-GObject-WARNING **: value "0" of type 'gint' is invalid or out of range for property 'dnd-drag-threshold' of type 'gint'
https://bugzilla.gnome.org/show_bug.cgi?id=749256
Slightly edited to fix up whitespace issues.
Edited-by: Emmanuele Bassi <ebassi@gnome.org>
The paint opacity for a top level is always overridden to be the full
value, since it's a composited value and we want to paint our scene.
When clearing the stage framebuffer, though, we want to use the actual
opacity, if ClutterStage:use-alpha is set.
-1 is explicitly an invalid value to pass to eglSwapBuffersWithDamage,
and the specification admits as much:
If
eglSwapBuffersWithDamageEXT is called and <n_rects>, is less
than zero or <n_rects> is greater than zero but <rects> is
NULL, EGL_BAD_PARAMETER is generated.
Fix up our usage of SwapBuffersWithDamage to match the behavior in the
EGL specification.
https://bugzilla.gnome.org/show_bug.cgi?id=745512
These are just terrible API that we've been stringing along since the
0.x days. We cannot truly deprecate them, because they are, in some
cases, the only actual API to perform some operation, and porting all
the code in the world is not going to make us any friends.
For the time being, we use a deprecation notice in the documentation.
The macros are useless for language bindings, and are terribly unsafe
from C as well. There's always the option of using the GObject
properties they refer to, but it's more efficient to just have a simple
getter function.
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
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.
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.
