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.
Point to ClutterImage, ClutterContent, and ClutterActor where needed, so
that developers trying to port their code will have a chance at figuring
out how.
Nobody has been compiling Clutter with profiling enabled in a long time.
UProf itself hasn't been updated in 5 years, and it still depends on
deprecated components like dbus-glib, with no port to GDBus in sight.
The profiling code was moderately useful in the past, but these days
it's probably better to profile Cogl than Clutter itself; timing
information can be extracted by the timestamp on each diagnostic message
that is now available by default in the CLUTTER_NOTE macro, and we can
add ad hoc counters where needed.
Add clutter_x11_set_use_stereo_stage() that can be called
before clutter_init() so that the CoglDisplay we create and all
stages created from that CoglDisplay will be created with a
stereo fbconfig.
This is done in clutter-x11 because of the similarity to the
existing clutter_x11_set_use_argb_visual(), and because it's
not clear without other examples whether the need to have
stereo enabled from before clutter_init() is universal or
somethign specific to GLX.
Cogl required version is increased to 1.20, which has the
required API.
https://bugzilla.gnome.org/show_bug.cgi?id=732706
Added support for Mir, now clutter can natively draw on MirSurfaces.
This depends on latest cogl git.
Run your clutter apps using CLUTTER_BACKEND=mir
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Toolkits may need to paint actors internally outside the normal tree
(for example to create a shadow shape), in which case they need to
control the opacity directly.
https://bugzilla.gnome.org/show_bug.cgi?id=677412
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
