The ClutterOffscreenEffect.get_target_size() method has been deprecated,
and replaced by the get_target_rect() one. We can easily switch to the
latter, and avoid the deprecation warning.
https://bugzilla.gnome.org/show_bug.cgi?id=670004
The target size is not always enough, there are cases where the offset
used to paint the target must also be available for developers
implementing an OffscreenEffect.
The get_target_rect() method returns the rectangle used to paint the
target, with the offsets in the ClutterRect:origin and the texture size
in the ClutterRect:size fields, respectively.
The get_target_size() method should be deprecated, given that its
replacement is generally more useful.
https://bugzilla.gnome.org/show_bug.cgi?id=670004
If we pass TRUE for x_align and FALSE for y_align, the full available
width should be passed to clutter_get_preferred_height, and the same
should be true in the other dimension.
https://bugzilla.gnome.org/show_bug.cgi?id=694237
Instead of directly accessing the instance fields. This removes a
compiler warning after the constification of g_get_prgname(), and it
seems to me to be generally more correct.
Instead of using a custom apply_transform(), paint(), and pick()
implementations, we can simply apply a transformation to the children of
a ScrollActor.
https://bugzilla.gnome.org/show_bug.cgi?id=686225
As wayland-client.h and wayland-server.h can't be included together,
split the Wayland backend file into clutter-backend-wayland.h, which
only defines the types, and clutter-backend-wayland-priv.h, which
actually uses the Wayland client types.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692851
The definition of wl_display differs between Wayland clients and
servers, and it's unsafe to include both wayland-client.h and
wayland-server.h at the same time. Fudge around this by making the
compositor public API use void * rather than struct wl_display *.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692851
This function is deprecated and has been replaced by set_display() on
the renderer. This is done in the get_renderer() vfunc of both the x11
and gdk backends already.
Actually cogl_xlib_set_diplay() is now a no-op and can be safely removed.
https://bugzilla.gnome.org/show_bug.cgi?id=687652
Being able to set a marker at a normalized point on a timeline, instead
of using a specific time, is a nice fit with the current Timeline class
API.
https://bugzilla.gnome.org/show_bug.cgi?id=694319
If anything in the system changes the config for fontconfig then an
XSetting will be set to record the last timestamp of the config file.
This is presumably so that applications can be notified that it has
changed and can reload the configuration. However once this setting is
set it will remain set for the lifetime of the X server. This causes
Clutter to handle the setting during the initialisation of the
backend. Previously this would cause problems because Clutter would
end up creating the default PangoFontMap before the backend has
created the CoglContext. The PangoFontMap would in turn cause the
default CoglContext to be created. Clutter will then later create its
own CoglContext which means there will be two and the first one will
be leaked. Cogl currently can't really cope with multiple contexts
being created so it falls apart.
This patch fixes it to skip reloading the config for fontconfig if
there isn't a default font map yet. The config will presumably
naturally be read with the latest values when it is finally created
anyway so it doesn't need to be read immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=693696
New experimental API is added to allow changing the way that redraws
are timed for a stage to include a "sync delay" - a period after
the vertical blanking period where Clutter simply waits for updates.
In detail, the algorithm is that when the master clock is restarted
after drawing a frame (in the case where there are timelines running)
or started fresh in response to a queued redraw or relayout, the
start is scheduled at the next sync point (sync_delay ms after the
predicted vblank period) rather than done immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=692901
In commit 8f4e39b6d7 the Wayland code was updated to use the new
xkbcommon API. This involved changing the common XKB code shared with
the evdev input backend. However the evdev input backend was not
modified so it wouldn't compile. This patch just makes a minor change
to update it.
https://bugzilla.gnome.org/show_bug.cgi?id=693348
Use the buffer_age extension when available to recycle backbuffer contents
instead of blitting from the back to front buffer when doing clipped redraws.
The picking is now done in a pixel that is going to be repaired during the next
redraw cycle for non static scences.
This should improve performance and avoid tearing.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=669122
This allows us to report to the backend that the stage's back buffer has been trashed
while handling picking. If the backend is keeping track of the contents of back buffers
so it can minimize how much of the stage is redrawn then it needs to know when we do pick
renders so it can invalidate the back buffer.
Based on patch from Robert Bragg <robert@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=669122
The behaviour imitates GtkEntry and ignores attributes from markup because Pango
barfs on invalid markup. Also add an example to the text-field interactive test.
https://bugzilla.gnome.org/show_bug.cgi?id=686477
As x11 considers num lock and scroll lock to be modifiers, code that
checks for an exact modifier combination will fail if naively done when
num lock or scroll lock are turned on. Applications that want to ignore
these modifiers will need to use XKB to manually mask out the modifier
state.
As it is very unlikely that applications will want to care about the
state of num lock or scroll lock for key press/key release events, mask
out the num lock and scroll lock keys automatically.
https://bugzilla.gnome.org/show_bug.cgi?id=690664
This has been disabled since February 2008, on the grounds that XFixes
didn't work reliably for hiding cursors. This has almost certainly been
fixed then and seems to work entirely reliably across a number of X
servers released in the past few years, and is definitely better than a
1x1 black dot for a cursor.
Helpfully though, where the spec states that the cursor will be hidden
when inside the specified window or one of its children, it actually
only uses the window to look up the Screen, and hides the cursor across
the entire Screen. So, when using this, we also need to track crossing
events.
If it's still broken, this needs to be fixed in the X server.
https://bugzilla.gnome.org/show_bug.cgi?id=690497
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
