On Mon, 31 Dec 2012 08:50:19 +0900 Cedric BAIL <cedric.b...@free.fr> wrote:
> On Sat, Dec 29, 2012 at 12:12 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: > > On Fri, Dec 28, 2012 at 11:32 PM, Cedric BAIL <cedric.b...@free.fr> > > wrote: > >> On Fri, Dec 28, 2012 at 1:33 PM, Gustavo Sverzut Barbieri > >> <barbi...@profusion.mobi> wrote: > >> > On Friday, December 28, 2012, Cedric BAIL wrote: > >> >> On Fri, Dec 28, 2012 at 12:32 PM, Gustavo Sverzut Barbieri > >> >> <barbi...@profusion.mobi <javascript:;>> wrote: > >> >> > On Thu, Dec 27, 2012 at 11:08 PM, Cedric BAIL > >> >> > <cedric.b...@free.fr > >> <javascript:;>> > >> >> wrote: > >> >> >> On Wed, Dec 19, 2012 at 1:27 AM, Enlightenment SVN > >> >> >> <no-re...@enlightenment.org <javascript:;>> wrote: > >> >> >> > Log: > >> >> >> > ecore-evas: Async render <snip> > > I have noticed that there is no GL async implementation. Is it > > planned > >> ? Do you have any idea how to fix all those GL direct rendering > >> call ? > > > > the direct rendering is easy, we just need to give those functions > > do_async. > > > > what is hard and not in our plans to touch is how to mix main > > thread with render thread. If evas was the only GL player out > > there, all the calls could be sent to the render thread, but the > > main thread may be doing GL as well. Also the map/proxy case right > > now is in the main thread, which would make the former case void. > > The proxy/map could be moved to the thread in theory, because it's > > ordered, then the surface would be ready when its usage is done, > > but we're on the safe side. > > > > For GL the biggest problem is how to lock it and avoid other > > threads (main) to don't do the make-current. The infrastructure > > allows that, but the implementation will be dependent on drivers && > > application. :-( > > Couldn't we use the fact that we have EvasGL to do the lock at that > level properly ? I can see a potential problem here with my work to integrate a 3D rendering library (Irrlicht) with EFL. The one I chose is not thread safe, and not likely to become thread safe any time soon. I'm using EvasGL so that it can integrate well with whatever else the EFL might be doing. At the moment I'm looking at using an animator to call the Irrlicht rendering calls at the EFL frame rate. Irrlicht does it's own make-current at this time, buried deep in it's rendering functions. If I remember, EFL callbacks are guaranteed to be called in the main thread, so that you can safely call other EFL functions and not worry about thread safety. Certainly it will be important to call the Irrlicht render functions on the same thread that called it's init functions, which will most likely be the main thread. The problems are likely no matter what 3D library is used though. They are all likely to do their own make-current at rendering time. Calling their rendering calls during an EFL animator callback is a very likely method of integration. But other people might want to do things differently. The non rendering 3D library functions might not be thread safe, and might be setting up data structures to be used by the rendering functions. The problem is that now you want to avoid doing the make-current on the main thread. And now the EFL rendering is also not gonna be on the main thread. This will make it hard to use other peoples 3D libraries. It's already hard enough. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
