Thanks Robert, I'll have a go with the patch. Will this benefit with textures being rendered to by Cairo?
Thanks, Steve On Thu, Sep 25, 2008 at 9:48 AM, Robert Bragg <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-24 at 20:39 +1000, Steve Smith wrote: >> Hi, >> >> I'm working on simple scrolling-graph app in Python with Clutter and >> Cairo. The scolling works by sliding a Cairo texture across with a >> simple Path Behaviour and once it reaches the end returns it to the >> start and redraws the graph shifted with new data appended to the end. >> >> The problem is that the time taken to redraw the Cairo texture causes >> a visible pause on all but the fastest machines. The obvious method >> to avoid this is to draw the next texture in the background while the >> first is scrolling and then flip them at the end (double-buffering >> basically). I /could/ do this in a separate thread but I'd rather >> avoid this and was wondering if there is a better method of utilising >> idle time in the background? Any tips would be appreciated. > Hi Steve, > > Yeah I'm fairly sure we are going to start seeing more and more of these > kinds of problems as people start writing Clutter apps involving slow to > render scenes. Unless you are running on a high end system then a single > threaded Clutter just can't avoid blocking the mainloop while rendering > the scene, in turn that will inevitably affect how quickly clutter can > deal with input events further impacting user experience. We've been > discussing this quite a bit recently. I don't believe you can work > around this via idle handlers, or making your application > multi-threaded; instead you need to find tricks to reduce your scene > render time. (It's appreciated that's not ideal.) > > The nicest approach we've come up with so far seems to be getting > Clutter to internally push the rendering out to a worker thread by > moving the calls to glXSwapBuffer into a new thread. Since writing multi > threaded GL apps is pretty common amongst game developers etc I think > there should be very little risk for Clutter to internally start doing > GL calls from different threads. This approach also completely hides > threading issues from developers. (Usually for the win!) > > Neil Roberts has even implemented all this already, yay! You can track > its progress here: > http://bugzilla.o-hand.com/show_bug.cgi?id=1118 > > The main caveat is that it requires a new approach to picking since we > currently have an API that lets you synchronously query the actor at > some stage position. Picking requires an offscreen render, so to allow > it to be pushed into the worker thread, the picking API now takes a > callback that gets called only when the render is complete and we have a > result. > > Note, this stuff is still in the stages of discussion/experimentation, > so no guesses if this will actually make it into Clutter proper any time > soon, or if we might come up with a different approach. If you are > interested in experimenting with the patches please feel free to give > feedback. Of course you'll also need to tweak the python bindings for > clutter_stage_get_actor_at_pos yourself for now. > > kind regards, > - Robert > > > -- To unsubscribe send a mail to [EMAIL PROTECTED]
