On Mon, Dec 31, 2012 at 1:37 PM, David Seikel <onef...@gmail.com> wrote: > On Mon, 31 Dec 2012 12:50:04 +0900 Cedric BAIL <cedric.b...@free.fr> > wrote: > >> On Mon, Dec 31, 2012 at 12:25 PM, David Seikel <onef...@gmail.com> >> wrote: >> > 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. >> >> Not really relevant to this thread, but you should just add an >> animator that do call evas_object_image_pixels_dirty_set on the >> Evas_Object_Image and make all Irrlicht handle in the callback set >> with evas_object_image_pixels_get_callback_set. > > It is relevant, the thread started talking about how async render > impacts EvasGL usage. My concerns will be the concerns of anyone > trying to use some random 3D rendering library package with EFL. EFL > really only does 2D, it has no good support for 3D apps, it needs a > decent 3D render engine. That's why I'm trying to get EFL and Irrlicht > to work well together. I think Irrlicht is a good match for EFL. But > my concern is not Irrlicht specific, it's a general concern for other > people using 3D libraries as well. Or even heavy GL users.
No, your concern were totally relevant, just my remark was not really relevant to the rest of the thread :-) > I'll try that when I next get time to play with it. Yep, let me know. > I think that still leaves the problem of the non render calls now > likely to be in the wrong thread. Setup stuff is likely to be done in > the main thread. General tweakage of 3D engine stuff is likely done > outside of the render callback. For example, your game decides it's > time to add some new 3D object, that decision is likely not done in the > render callback. This sort of thing should be well documented, and > good examples of how to deal with async EvasGL rendering, third > party GL libraries, and heavy GL usage. Indeed. > Hmm, this might be why the ELM GL examples are now broken, which > means "told you so". :-P They work for me with GL backend, but not with the software backend. -- Cedric BAIL ------------------------------------------------------------------------------ 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
