Re: [clutter] Linking actors in 3D
Hi Felipe,
Filipe Nepomuceno wrote:
very expensive solution though (if it works) because of the trig
function calls
You can always just precompute the trig values into an array or use a
polynomial approximation. You just need to clamp the angle to the right
range in an accessor function in which you determine the right array
index to request.
get_cos(angle) {
clamp(angle); // clamping to 0 to 2*PI range
index = (int)((angle/(2*PI))*array_size);
return cos_array[index];
}
This is much much faster than using the C trig functions. You can reduce
precomputations by storing only 0 to PI/2, but then the clamping logic
is messier.
-Bartek
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] event coordinates from an event on a group are relative to stage
Emmanuele Bassi wrote: It would be nice to have a way to convert coordinates between arbitrary actors though. clutter_actor_apply_relative_transform_to_point() is the function you want. remember, though, that transformations are performed by the CPU and might be costly or even fail. Hey, thanks a lot, I should probably take a deeper look at the api reference for clutter in addition to that for cluttermm. As for the speed: I'm sure my own transformation functions aren't any faster and I can't do without them to do what I'm doing. Bartek -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] event coordinates from an event on a group are relative to stage
Hi, when a group is made reactive and receives a mouse event the event coordinates are relative to the stage. Because the group coordinates rotate and transform with the group (so that x in a rotated group is actually a position along a possibly diagonal line) one cannot easily make natural comparisons between the coordinates of the event and coordinates on the group grid. Does clutter provide transform matrices for this purpose? Wouldn't it make sense to have events received by a group automatically produce coordinates relevant there? Thanks, Bartek -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] button release not caught if not on actor
Rajith Kalluraya wrote: Hi, You can do a clutter_grab_pointer on the scrollbar widget in its button press handler. Motion events and the release events will be received by the scrollbar widget no matter where the mouse is. Make sure you call clutter_ungrab_pointer in the release handler. That should so the trick. Thanks a lot. Unfortunately it's just a partial fix even with my workarounds. I have separate animations for hover (enter/leave - opacity increase/decrese) and click/release. Now when I grab the pointer, the enter/leave boundaries become those of the stage, and my hover highlight stays lit when the mouse button is released outside of the element boundaries but within the stage boundaries. I can't unlight it in the button_release signal handler because the pointer might have ended up hovering over the element at the end of the scrolling operation, so it must remain lighted. That is, unless there is a way to check whether the pointer is currently above a given element. Any more ideas? -Bartek -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] cluttermm: deriving from Clutter::Texture
Murray Cumming wrote: On Sun, 2009-06-07 at 12:05 +0200, Bartosz Kostrzewa wrote: Attached is a simple test case which explains what the problem is. The ending of Clutter::main() does not remove actors from the stage. stage-remove_actor(object) has to be called explicitly for the reference count of object to be decremented properly. I would consider this a bug taking into account how dynamic instantiation can be in C++. Can you add this to bugzilla, please? gnomemm/cluttermm in bugzilla.gnome.org. I couldn't find cluttermm in the projects list. I'll take another look. I'll change the description to destructors of actors on the stage not called when cluttermm application is quit I can't promise to take a look at this particularly soon, but I wouldn't want us to forget about it. Sure, exactly my thought. -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] cluttermm: deriving from Clutter::Texture
Emmanuele Bassi wrote: On Sun, 2009-06-07 at 12:05 +0200, Bartosz Kostrzewa wrote: Attached is a simple test case which explains what the problem is. The ending of Clutter::main() does not remove actors from the stage. this is how Clutter works; the scenegraph is *not* destroyed at the end of the main loop, because the loop can be stopped and restarted. destroying the scene would be wrong. Ok, I can accept that, you're obviously right. I think I should rephrase it as: when the application ends, because that is the actual problem. if you are quitting the application it doesn't matter, the allocated memory will be reclaimed by the OS. I see, but the destructors are not called when you quit the application, which is a problem. if you are not quitting the application and you want to restart the main loop with a clean slate, just remove all actors from the stage (if it is the default one) or destroy the stage (if it was created with clutter_stage_new()). Yes, agree 100%. Anything else would be wrong. ciao, Emmanuele. Thanks. -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] cluttermm get_scale behaving strangely
Hi everyone, I have a simple UI which relies in its logic on calling get_scale to control an animation but I've noticed that while an actor is being animated via calling set_scale in a *new_frame signal handler, get_scale keeps returning 1.0 until about half a second after the timeline animating the set_scale operation has finished. (specifically I'm scaling textures to the shortest stage dimension when they are clicked and back to their original dimensions when they are clicked again, the second step relying on get_scale returning a result bigger than 1.0) Is this expected behaviour? Is there something I can do to guarantee that the value of set_scale is propagated so that get_scale returns the correct one? Thanks. -Bartek -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] cluttermm get_scale behaving strangely
Bartosz Kostrzewa wrote: animated via calling set_scale in a *new_frame signal handler, get_scale keeps returning 1.0 until about half a second after the timeline animating the set_scale operation has finished. apologies for replying to my own post but it's not even as regular as that. In effect what happens is that during the animation, get_scale returns the correct instantaneous value (output in the new_frame handler), however, once the animation is complete, for some reason the returned values are sometimes correct, and sometimes 1.0... could it be that get_scale relies on the whole texture being inside the stage boundaries? -Bartek -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] cluttermm get_scale behaving strangely
Bartosz Kostrzewa wrote: Is this expected behaviour? Is there something I can do to guarantee that the value of set_scale is propagated so that get_scale returns the correct one? Ok, disregard this, the problem was that clicking triggered the animation of an underlying texture which was completely hidden from view, thus it seemed as though something fishy was going on while that was not the case. Seems like I need to adjust the z position as well as the scale to be safe. -Bartek -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
