On Sun, 2009-01-18 at 15:21 -0500, Jason Tackaberry wrote: > On Sun, 2009-01-18 at 10:32 -0500, Jason Tackaberry wrote: > > 3. If not, is there some alternative approach, equivalent in > > functionality, for which a patch would be accepted? > > I discovered one possible solution: attach two handlers with > clutter_threads_add_idle_full(), one at priority > CLUTTER_PRIORITY_REDRAW-10 that waits for the appropriate retrace, and > another at priority CLUTTER_PRIORITY_REDRAW that validates the current > retrace and unlocks the frame buffer. > > I don't have a sense yet as to how reliable this method is, however. A > 'redraw' signal for ClutterBackend is conceptually cleaner.
I'd contend on the idea that having a ::redraw signal is the cleaner solution to *any* problem. let me see if I understand what you're trying to achieve: you want to be able to make Clutter's redraw cycle depend on another set of conditions -- basically, "slaving" Clutter's redraw to another redraw cycle. for that, Clutter 1.0 will have the ::queue-redraw signal on the ClutterStage: you connect to the signal (which is invoked when something queues a redraw on a ClutterStage), block it, queue a redraw on your redraw cycle and then let that cycle call clutter_redraw(). this won't be backported to the current stable cycle, though. otherwise, I need to understand what are you trying to achieve. ciao, Emmanuele. -- Emmanuele Bassi, Intel Open Source Technology Center -- To unsubscribe send a mail to [email protected]
