cogl_path_new now takes a CoglContext pointer which it keeps a pointer
to instead of relying on the global context.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit afc63f8211c230f8fd1f7801f9085627c46a8661)
Since we can't change the api on this branch this just applies
the internal cleanups so we depend less on _COGL_GET_CONTEXT
This splits the GL header inclusion from cogl-defines.h into a
separate headear called cogl-gl-header.h which we will only include
internally. That way we don't leak GL declarations out of our public
headers. The texture functions that were using GLenum and GLuint in
the public header have now changed to just use unsigned int. Note
however that if an EGL winsys is enabled then it will still publicly
include an EGL header. This is a bit more awkward to fix because we
have public API which returns an EGLDisplay and we can't determine
what type that is.
There is also a conformance test which just verifies that no GL header
has been included while compiling. The test isn't added to
test-conform-main because it doesn't actually test anything at
runtime.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit ef5680d3fda5df929dbd0b420c8f598ded58dfee)
cogl_framebuffer_draw_multitextured_rectangles is not in the public
API list, it is instead _cogl_framebuffer_draw_multitextured_rectangles,
which is private.
(Sorry, I forgot to add the reviewed by line for the same patch in the
cogl-1.10 branch :P)
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 4fc6cf5e3c1478bc0a29dfaf2f6d9e84b9d29ccd)
We need to filter out all the *-egl-* sources as well, as the original
filter did not filter out the Wayland EGL sources
(Sorry, I forgot to add the reviewed by line for the same patch in the
cogl-1.10 branch :P)
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 3d4cb887a28d3bc2cde9e4e7cdd20a71c34a2eaa)
Not every single one, but things that we care about to avoid breaking
build on other platforms, or for security issues, should not be allowed.
We should not force everyone to use -Werror, though; and we should still
allow building Clutter without any special flag.
In order to identify whether the crossing event is an enter or a leave,
we should use the ClutterEventType enumeration, not attach a value to
the signal handler.
When dragging/scrolling using touch events, we want the same behaviour
than for motion events. We need to honor the user's calls to
clutter_stage_set_motion_events_enabled() to deactive event
bubbling/captured sequences on the actor located under the pointer and
just transmit events to the stage/grab actor.
https://bugzilla.gnome.org/show_bug.cgi?id=680751
We need to make sure that ClutterActor::transition-stopped is emitted
after the transition was removed from the actor's list of transitions.
We cannot just remove the TransitionClosure from the hash table that
holds the transitions associated to an actor, and let the
TransitionClosure free function stop the timeline, thus emitting the
::transition-stopped signal - otherwise, stopping the timeline will end
up trying to remove the transition from the hash table, and we'll get
either a warning or a segfault.
Since we know we're removing the timeline anyway, we can emit the signal
ourselves in case the timeline is playing, in both the implicit and
explicit cases.
The :transform property controls the modelview matrix of an actor; it
can be used to set a custom modelview matrix on the actor, as opposed
to the decomposed transformations (rotation, scaling, translation)
provided by the ClutterActor class.
The transitions we create implicitly should be removed from the set of
transitions associated to an actor; the transitions explicitly
associated to an actor, though, have to survive the emission of their
'stopped' signal.
We can remove the update_transition() private method, and move its
functionality inside the create_transition() private method, thereby
removing lots of duplicated code, as well as redundant checks on the
existence of a transition. This will allow handling transition updates
atomically in the future.
Another progress function from the CSS3 Transitions specification, using
a parametrices cubic bezier curve between (0, 0) and (1, 1) with two
control points.
(sadly, no ASCII art can approximate a cubic bezier, so no graph)
The cubic-bezier() progress function comes with a bunch of preset easing
modes: ease, ease-in, ease-out, and ease-in-out, that we can map to
enumeration values.
The CSS3 Transitions specification from the W3C defines the possibility
of using a parametrized step() timing function, with the following
prototype:
steps(n_steps, [ start | end ])
where @n_steps represents the number of steps used to divide an interval
between 0 and 1; the 'start' and 'end' tokens describe whether the value
change should happen at the start of the transition, or at the end.
For instance, the "steps(3, start)" timing function has the following
profile:
1 | x
| |
| x---|
| ' |
| x---' |
| ' |
0 |---' |
Whereas the "steps(3, end)" timing function has the following profile:
1 | x---|
| ' |
| x---' |
| ' |
x---' |
| |
0 | |
Since ClutterTimeline uses an enumeration for controlling the progress
mode, we need additional API to define the parameters of the steps()
progress; for this reason, we need a CLUTTER_STEPS enumeration value,
and a method for setting the number of steps and the value transition
policy.
The CSS3 Transitions spec helpfully also defines a step-start and a
step-end shorthands, which expand to step(1, start) and step(1, end)
respectively; we can provide a CLUTTER_STEP_START and CLUTTER_STEP_END
enumeration values for those.
This patch brings 'enter-event' and 'leave-event' generation for touch
based devices. This leads to adding a new API to retrieve coordinates
of a touch point.
https://bugzilla.gnome.org/show_bug.cgi?id=679797
