Hello, You can try to animate the anchor-x and anchor-y properties for scrolling. These properties affect only the paint phase, their animation should not retrigger allocation. This will avoid some python virtual method calls.
HTH, Julien 2010/4/30 Martin Wilz <martin.w...@gmail.com> > Hello, > > While not getting any further with my previous post, I tried to draw > something with clutter/COGL, which comes pretty near to the > use case I have in mind. The stage consists mostly of rounded > rectangles as implemented on http://www.themacaque.com/?p=565 > and labels, both of them put together in groups. Lots of them. > > Then I tried to animate it (scrolling ) and my CPU hit the limit and it > was nowhere near being smooth. I first thought, that maybe the hardware > acceleration is not working (I'm still not sure). I did some debugging and > came to conclusion, that there is first an issue with the do_paint method > in the rounded rectangle. It gets unnecessarily called, when each actor > is moved, as verified by print-debugging. > > I'm using group.animate(clutter.EASE_IN_OUT_SINE, 10000, "y", 500) > to animate, which I'm not sure is the right way to animate optimally. Are > there other ways of moving actors, which are less well documented (e.g > anchor points), but don't trigger an redraw of the actors, but work more > in the spirit of a transformation of actors rather than redrawing them ? > > As I did not find such a transformation, I tried to use > texture_new_from_actor with > my group, as these groups will change slowly and one at a time in the use > case. > Unfortunately texture_new_from_actor returns None on my system, even for > simple > objects such as Rectangles. I read something about the system needing the > feature > to render textures offscreen and checked the feature flags. > > import clutter f = clutter.FeatureFlags.__flags_values__ > for (i,v) in f.iteritems(): > ... print "%s:%s" % (str(v), clutter.feature_available(i)) > ... > <flags CLUTTER_FEATURE_STAGE_USER_RESIZE of type ClutterFeatureFlags>:True > <flags CLUTTER_FEATURE_STAGE_STATIC of type ClutterFeatureFlags>:False > <flags CLUTTER_FEATURE_SWAP_EVENTS of type ClutterFeatureFlags>:False > <flags CLUTTER_FEATURE_TEXTURE_NPOT of type ClutterFeatureFlags>:True > <flags CLUTTER_FEATURE_OFFSCREEN of type ClutterFeatureFlags>:True > <flags CLUTTER_FEATURE_TEXTURE_READ_PIXELS of type > ClutterFeatureFlags>:True > <flags CLUTTER_FEATURE_SYNC_TO_VBLANK of type ClutterFeatureFlags>:True > <flags CLUTTER_FEATURE_STAGE_CURSOR of type ClutterFeatureFlags>:True > <flags CLUTTER_FEATURE_TEXTURE_YUV of type ClutterFeatureFlags>:False > <flags CLUTTER_FEATURE_SHADERS_GLSL of type ClutterFeatureFlags>:True > <flags CLUTTER_FEATURE_STAGE_MULTIPLE of type ClutterFeatureFlags>:True > > As I interpret it, my (ATI 4550 with fglrx driver) system should be capable > to > use texture_new_from_actor. I already made sure the actor is not attached > to another > actor/stage and to show the actor before. Am I missing something else ? > > Oh yes, I saw that you are able to draw to textures directly with Cairo, > which seems to > be the currently recommended way to generate textures. Are there any > caveats when > using this approach other than having to look at just another drawing API ? > > Martin > > > >
