summaryrefslogtreecommitdiff
path: root/clutter/clutter-timeline.c
Commit message (Collapse)AuthorAgeFilesLines
* timeline: Add more debug outputPhilip Withnall2015-09-211-2/+22
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=755357
* timeline: Ensure waiting_first_tick is set before adding the timelinePhilip Withnall2015-09-211-1/+1
| | | | | | | Just in case the timeline starts being prodded by the ClutterMasterClock before the add function returns. (This has not been verified.) https://bugzilla.gnome.org/show_bug.cgi?id=755357
* docs: Move to markdownEmmanuele Bassi2014-03-171-25/+22
| | | | We're removing docbook tags in favour of the markdown syntax.
* timeline: Fix bad logic in checkEmmanuele Bassi2014-02-101-8/+8
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=711540
* Use the new macros for adding private dataEmmanuele Bassi2013-07-031-18/+13
|
* timeline: Ensure the range on the cubic bezier control pointsEmmanuele Bassi2013-04-051-0/+5
| | | | The X coordinate has to be in the [ 0.0, 1.0 ] range.
* timeline: Use the right function pointer offsetEmmanuele Bassi2013-03-051-1/+1
| | | | | | | A copy and paste thinko: the ::stopped signal is using the ClutterTimelineClass.completed slot instead of the .stopped one, thus preventing sub-classes of ClutterTimeline from overriding the signal's default closure.
* timeline: Add progress-based marker APIEmmanuele Bassi2013-02-201-26/+120
| | | | | | | | 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
* timeline: Add cubic-bezier() progress functionsEmmanuele Bassi2012-07-191-0/+103
| | | | | | | | | | | | 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.
* timeline: Add support for step() progressEmmanuele Bassi2012-07-191-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* docs: Mention the Timeline::stopped signal in the class descriptionEmmanuele Bassi2012-06-131-3/+5
| | | | | | Now that we have the ::stopped signal, it would be good if the documentation mentioned it explicitly as the dual of the ::started signal.
* timeline: Emit last ::completed before ::stoppedEmmanuele Bassi2012-06-131-2/+4
| | | | | | | | | | | | The ::stopped signal should be emitted at the end of the Timeline, after the last ::completed signal emission, in order to have a proper chronological progress of signal emissions: started → new-frame → [ ... ] → completed → stopped This way, ::stopped can perform a proper teardown of the state set up during ::started, without interfering with the potential cyclical emission of ::completed.
* timeline: Add a new "stopped" signalEmmanuele Bassi2012-05-311-5/+51
| | | | | | | | | | | | | The ::stopped signal is emitted when the timeline has been completely exhausted or when the timeline has been programmatically stopped by using clutter_timeline_stop(); the notification at the end of the timeline run allows to write handlers without having to check whether the current repeat is the last one, like we are forced to do when using the ::completed signal. Based on the patch by: Jasper St. Pierre <jstpierre@mecheye.net> https://bugzilla.gnome.org/show_bug.cgi?id=676854
* docs: Annotation fixesEmmanuele Bassi2012-04-301-1/+1
| | | | | | The introspection scanner has become slightly more annoying, in the hope that people start fixing their annotations. As it turns out, it was the right move.
* timeline: Add an internal function for advancing a timelineEmmanuele Bassi2012-04-271-4/+22
| | | | | | | There are cases when we want to advance a timeline from another time source. We cannot use _clutter_timeline_do_tick() directly, as that assumes that the timeline is already playing, so we'll need to create a wrapper that toggles the playing flag around it.
* easing: Add utility functionsEmmanuele Bassi2012-04-271-54/+1
| | | | | We end up copying the same array-of-modes-and-functions code in various places, so it's better to factor it out.
* timeline: Increment current-repeat after ::completedEmmanuele Bassi2012-03-191-2/+2
| | | | | | The ::completed signal emission is part of the current cycle; repeating, like the automatic reverse of the timeline's direction, happens after the ::completed chain of handlers has been called.
* timeline: Add more state accessorsEmmanuele Bassi2012-03-151-0/+54
| | | | | | | | | It should be possible to ask a timeline what is its duration, taking into account eventual repeats, and which repeat is the one currently in progress. These two functions allow writing animations that depend on the current state of another timeline.
* Fix missing/redundant declarationsEmmanuele Bassi2012-03-071-1/+4
|
* Fix the progress function scope annotationEmmanuele Bassi2012-02-231-1/+1
|
* timeline: Add progress functionsEmmanuele Bassi2012-02-231-13/+236
| | | | | The whole progress computation should not be done using a separate class: it should be part of the Timeline class.
* timeline: Add repeat-countEmmanuele Bassi2012-02-131-34/+147
| | | | | | | | | | | | | | | | | Being able to easily set the number of repeats has been a request for the animation framework for some time now. The usual way to implement this is: connect to the ::completed signal, use a static counter, and stop the timeline when the counter hits a specific spot. In the same light as the :auto-reverse property, we can make it easier to implement this common functionality by adding a :repeat-count property that, when set, limits the amount of loops that a Timeline can perform before stopping itself. In fact, we can implement the :loop property in terms of the :repeat-count property just by using a sentinel value mapping to "infinity", and map loop=FALSE to repeat-count=0, and loop=TRUE to repeat-count=-1.
* timeline: Deprecate the clone() methodEmmanuele Bassi2012-02-131-6/+13
| | | | | | | | | | | | The clutter_timeline_clone() method was a pretty dumb idea when it was introduced, back when we still had the ClutterEffectTemplate and the clutter_effect_* animation API. It has since become an API wart: we cannot change or add new properties to be cloned without the risk of breaking existing code. All in all, cloning a GObject is just a matter of calling g_object_new() with the wanted properties. Let's deprecate this throwback of the Olden Days™, so that we can remove it for good once we break for 2.0.
* Fix compiler warningsEmmanuele Bassi2012-01-161-1/+1
| | | | | | When dereferencing GArray.data to a C structure you need a double cast from guint8* to void*, and then from void* to the actual type. This avoids compiler warnings, especially when using clang on OSX.
* timeline: Add custom parser for "markers"Emmanuele Bassi2011-11-271-32/+230
| | | | | | | | | | | | | | It should be possible to define markers in ClutterScript when describing a ClutterTimeline. The syntax is a trivial: "markers" : [ { "name", <marker-name>, "time" : <msecs> } ] While at it, we should document it inside the API reference, as well as fleshing out the ClutterTimeline description.
* Remove CLUTTER_TIMESTAMP debug macroEmmanuele Bassi2011-11-151-3/+3
| | | | | | It's pretty much unused, and it doesn't print out really informative messages. We should make CLUTTER_NOTE print out a decent timestamp instead.
* docs: Fix the ClutterTimeline:auto-reverse linkEmmanuele Bassi2011-09-021-1/+1
|
* docs: Remove mentions of "frames" in TimelineEmmanuele Bassi2011-09-021-1/+1
| | | | We still have some really old naming lying around.
* timeline: Cast elapsed time before emitting ::new-frameEmmanuele Bassi2011-07-181-2/+4
| | | | | | | | | | | | When emitting a new-frame signal, priv->elapsed_time is passed as a parameter. This is a gint64. The closure marshal uses an INT. On some platforms, this is not received correctly by signal handlers (they receive 0). One solution is to cast priv->elapsed_time to a gint when emitting the signal. We cannot change the signature of the signal without breaking ABI. https://bugzilla.gnome.org/show_bug.cgi?id=654066
* Remove private helper #define'sJasper St. Pierre2011-03-031-9/+9
| | | | | | Finish off the second half of 09a830d294. http://bugzilla.clutter-project.org/show_bug.cgi?id=2596
* clutter-timeline: Emit the new-frame signal even on the first frameNeil Roberts2011-01-241-0/+2
| | | | | | | | | | | ClutterTimeline has special handling for the first time do_tick is called which was not emitting a new-frame signal. This meant that an application which directly uses the timeline would have to manually setup the initial state of an animation after starting a timeline to avoid painting a single frame with the wrong state. It seems to make more sense to instead emit the new-frame signal so that the application always sees a new-frame when the progress changes before a paint.
* timeline: Check if the timeline is playing in do_tickChris Lord2011-01-181-0/+8
| | | | | | | Check that the timeline is still playing before executing in _clutter_timeline_do_tick. This fixes the possibility of receiving a new-frame signal when stopping a timeline in response to a different timeline's signal emission.
* timeline: Rename the reverse property to auto-reverseEmmanuele Bassi2010-12-171-29/+28
| | | | | | Other frameworks expose the same functionality as "auto-reverse", probably to match the cassette tape player. It actually makes sense for Clutter to follow suit.
* timeline: Add :reverse propertyEmmanuele Bassi2010-11-181-19/+137
| | | | | | | The :reverse property removes the pattern of connecting to the ::completed signal of a Timeline to change the direction. http://bugzilla.clutter-project.org/show_bug.cgi?id=2408
* Move away from GTimeValEmmanuele Bassi2010-11-171-9/+8
| | | | | | | | | | | | | | | | | | | | GLib 2.28 will deprecate GTimeVal and related API in favour of standardizing on microseconds granularity for all time-based API. Clutter should switch too. All of the current users of GTimeVal convert to milliseconds when doing time operations, and use GTimeVal only as storage. This can effectively be replaced by a gint64. The Master Clock uses a microsecond resolution, except when interacting with the main loop itself, since the main loop has a millisecond resolution - at least until Ryan Lortie manages to switch that too to microseconds on Linux. The clutter_timeline_do_tick() function was erroneously not privatized, but it was still assumed to be private; we should just remove it from the public symbols.
* Move more classes to install_properties()Emmanuele Bassi2010-10-181-37/+35
|
* introspection: Add annotationsEmmanuele Bassi2010-09-031-4/+5
| | | | Reduce the amount of warnings coming from g-ir-scanner.
* Conditionally use g_object_notify_by_pspecNeil Roberts2010-08-101-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a wrapper macro to clutter-private that will use g_object_notify_by_pspec if it's compiled against a version of GLib that is sufficiently new. Otherwise it will notify by the property name as before by extracting the name from the pspec. The objects can then store a static array of GParamSpecs and notify using those as suggested in the documentation for g_object_notify_by_pspec. Note that the name of the variable used for storing the array of GParamSpecs is obj_props instead of properties as used in the documentation because some places in Clutter uses 'properties' as the name of a local variable. Mose of the classes in Clutter have been converted using the script in the bug report. Some classes have not been modified even though the script picked them up as described here: json-generator: We probably don't want to modify the internal copy of JSON behaviour-depth: rectangle: score: stage-manager: These aren't using the separate GParamSpec* variable style. blur-effect: win32/device-manager: Don't actually define any properties even though it has the enum. box-layout: flow-layout: Have some per-child properties that don't work automatically with the script. clutter-model: The script gets confused with ClutterModelIter stage: Script gets confused because PROP_USER_RESIZE doesn't match "user-resizable" test-layout: Don't really want to modify the tests http://bugzilla.clutter-project.org/show_bug.cgi?id=2150
* Hide the marshallersEmmanuele Bassi2010-06-111-5/+5
| | | | | | | | The marshallers we use for the signals are declared in a private header, and it stands to reason that they should also be hidden in the shared object by using the common '_' prefix. We are also using some direct g_cclosure_marshal_* symbol from GLib, instead of consistently use the clutter_marshal_* symbol.
* Remove mentions of the FSF addressEmmanuele Bassi2010-03-011-3/+3
| | | | | | | | | | | | | | | Since using addresses that might change is something that finally the FSF acknowledge as a plausible scenario (after changing address twice), the license blurb in the source files should use the URI for getting the license in case the library did not come with it. Not that URIs cannot possibly change, but at least it's easier to set up a redirection at the same place. As a side note: this commit closes the oldes bug in Clutter's bug report tool. http://bugzilla.openedhand.com/show_bug.cgi?id=521
* analysis: ClutterTimelineEmmanuele Bassi2010-02-121-4/+0
| | | | Remove an unused variable.
* [timeline] Account for clock roll backs between framesEmmanuele Bassi2009-09-161-10/+23
| | | | | | | | | | | | If the system clock rolls back between two frames then we need to account for the change, to avoid stopping the timeline. The best option, since a roll back can be any arbitrary amount of milliseconds, is to skip a frame. Fixes bug: http://bugzilla.moblin.org/show_bug.cgi?id=3839
* Remove the last few fixed-point entry pointsEmmanuele Bassi2009-06-191-16/+0
| | | | | | The last fixed-point entry points are just a few, and trivial. The end user is expected to do the conversion using the CoglFixed type and macros.
* [timelines] Improve marker hit check and don't fudge the deltaNeil Roberts2009-06-111-17/+85
| | | | | | | | | | | | | | | | | Markers added at the start of the timeline need to be special cased because we effectively check whether the marker time is greater than the old frame time or less than or equal to the new frame time but we never actually emit a frame for the start of the timeline. If the timeline is looping then it adjusts the position to interpolate a wrapped around position. However we do not emit a new frame after setting this position so we need to check for markers again there. clutter_timeline_get_delta should return the actual wall clock time between emissions of the new-frame signal - even if the elapsed time has been fudged at the end of the timeline. To make this work it no longer directly manipulates priv->msecs_delta but instead passes a delta value to check_markers.
* Revert "[timeline] Don't clamp the elapsed time when a looping tl reaches ↵Neil Roberts2009-06-111-93/+49
| | | | | | | | | | | | | | the end" This reverts commit 9c5663d6717722d6d77162060f284355b5081174. The patch was causing problems for applications that expect the elapsed_time to be at either end of the timeline when the completed signal is fired. For example test-behave swaps the direction of the timeline in the completed handler but if the time has overflowed the end then the timeline would only take a short time to get back the beginning. This caused the animation to just vibrate around the beginning.
* [timeline] Don't clamp the elapsed time when a looping tl reaches the endNeil Roberts2009-06-101-49/+93
| | | | | | | | | | | | | | | The new-frame signal of a timeline was previously guaranteed to be emitted with the elapsed_time set to the end before it emits the completed signal. This doesn't necessarily make sense for looping timelines because it would cause the elapsed time to be clamped to a slightly off value whenever the timeline restarts. This patch makes it perform the wrap around before emitting the new-frame signal so that the elapsed time always corresponds to the time elapsed since the timeline was started. Additionally it no longer fudges the msecs_delta property to make the marker check work so clutter_timeline_get_delta will always return the wall clock time since the last frame.
* Move elapsed-time calculations into ClutterTimelineOwen W. Taylor2009-06-091-14/+39
| | | | | | | | | | | | | | | | | | | | Instead of calculating a delta in the master clock, and passing that into each timeline, make each timeline individually responsible for remembering the last time and computing the delta. This: - Fixes a problem where we could spin infinitely processing timeline-only frames with < 1msec differences. - Makes timelines consistently start timing on the first frame; instead of doing different things for the first started timeline and other timelines. - Improves accuracy of elapsed time computations by avoiding accumulating microsecond => millisecond truncation errors. http://bugzilla.openedhand.com/show_bug.cgi?id=1637 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
* Simplify timeout list handling for the master clockOwen W. Taylor2009-06-091-10/+29
| | | | | | | | | | | Instead of keeping a list of all timelines, and connecting to signals and weak notifies, simply keep a list of running timelines; this greatly simplifies both the book-keeping, and also determining if there are any running timelines. http://bugzilla.openedhand.com/show_bug.cgi?id=1637 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
* [docs] Various gtk-docs fixesEmmanuele Bassi2009-06-091-49/+1
|
* Properly adjust msecs_delta when clamping elapsed timeOwen W. Taylor2009-06-081-3/+11
| | | | | | | | | | When we complete a timeline, we clamp the elapsed_time variable to the range of the timeline. We need to adjust msecs_delta so that when we check for hit markers we have the correct interval. http://bugzilla.openedhand.com/show_bug.cgi?id=1641 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
View Lorry Controller Status