On Fri, 2009-07-31 at 17:57 +0100, Øyvind Kolås wrote:
> On Thu, Jul 30, 2009 at 2:01 PM, Rajith Kalluraya<nsraj...@gmail.com> wrote:
> > which is CPU intensive.I observe that clutter queues redraws and and
> > processes them only when CPU is free, and hence in my application, the draw
> > happens after the CPU intensive job is done, thereby causing a delay in
> > screen updation.
>
> * snip *
>
> > Currently, I am using clutter 0.8 and clutter-gtk-0.8 on a ARM processor
> > with hardware acceleration.
>
> What you seem to be experiencing is not that the redrawing is delayed
> but that animations are being blocked. Clutter 1.0 changes how
> animations are driven and locks them to the redraw cycle; solving many
> idle priority related issues that existed in clutter-0.8 and before.
as a side note: there's no power in the 'verse that can make the main
loop work correctly when you're blocking it inside a handler -- say, for
instance, you have while(1) {} or g_usleep() in an event handler or
inside a Timeline::new-frame callback.
the usual answers for CPU-intensive blocks are:
- break them up in logical steps and use a state machine+idle/timeout
source in the main loop to avoid blocking.
- use threads and prepare to cross the plains of Despair and Rage,
ascend the mountains of Doom, pass the Peak of Terror, and finally
enter in a land made of unicorns and puppies where everything works
by the power of rainbows and magic pixie fairy dust.
for both solutions, Clutter provides API to do things The Right Way(tm),
including: a timeout pool, frame sources and repaint cycle hooks.
ciao,
Emmanuele.
--
Emmanuele Bassi, Senior Engineer | emmanuele.ba...@intel.com
Intel Open Source Technology Center | http://oss.intel.com
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
