After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 654066 - ClutterTimeline new-frame signal not working correctly on some platforms
ClutterTimeline new-frame signal not working correctly on some platforms
Status: RESOLVED FIXED
Product: clutter
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: clutter-maint
clutter-maint
Depends on:
Blocks:
 
 
Reported: 2011-07-06 02:02 UTC by Pablo Pissanetzky
Modified: 2011-07-18 14:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch to use gint64 for msecs in ClutterTimeline's new-frame signal (1.61 KB, patch)
2011-07-06 19:19 UTC, Pablo Pissanetzky 		none Details | Review

Description Pablo Pissanetzky 2011-07-06 02:02:41 UTC 
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. Another would be to define the signal using an INT64 as the elapsed parameter.
Comment 1 Emmanuele Bassi (:ebassi) 2011-07-06 09:47:35 UTC 
converting the signal definition to use int64 would probably be the best option. if you could cook up a patch it would be awesome.
Comment 2 Pablo Pissanetzky 2011-07-06 19:19:33 UTC 
Created attachment 191418 [details] [review]
Patch to use gint64 for msecs in ClutterTimeline's new-frame signal
Comment 3 Pablo Pissanetzky 2011-07-06 19:20:42 UTC 
The patch is attached, but note that if users of this code don't update their signal handlers to take a gint64, bad things will happen. This won't be caught by the compiler - it will be stack corruption at runtime.
Comment 4 Emmanuele Bassi (:ebassi) 2011-07-18 14:27:16 UTC 
in the end, I went for the "cast the int64 to an int before emitting the signal" approach because you were right, and it was the cleanest solution. thanks a lot for working on this!