On Mon, 31 Dec 2012 13:45:42 +0900 Cedric BAIL <cedric.b...@free.fr> wrote:
> 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. I tried your suggestion. The animator now just sets the pixels dirty (though in the case of not using OpenGL, it calls the evas_object_image_pixels_get_callback_set() callback itself, coz Evas_GL isn't running). That callback is now responsible for setting up all the Irrlicht stuff (if not previously setup), as well as calling the Irrlicht render routines. I suppose I could use similar methods for other non rendering Irrlicht calls, set a flag that it needs to be done, then do it in that rendering callback. This at least makes for a neat "deferred rendering" system. B-) That still leaves the problem of shutting things down. The image used for the GL rendering has a delete callback set, and that delete callback shuts down Evas_GL and Irrlicht. I highly doubt this callback is run on the render thread. It might be a problem trying to set a flag for one last frame of the animator to do the same "set a flag" thing being done above, coz the image itself is in the process of being deleted. That's the example method of dealing with Evas_GL shutdown, so the one most likely used. Also the easy way, since the deletion of the image is done for you, hence the reason for the deletion callback. Other than that, you would have to setup a complex series of events to let the animator do one last frame, with the "you are being shutdown" flag set, so Irrlicht can shut down in the same thread it started up in. Then once that has been done, you can shutdown Evas_GL and delete the image. Still gotta be careful about who shuts down what, with the GL context and surface being shared. Even if there was a direct "run this bit on the render thread" thingy, it would still get complex on shut down I fear. Also, still doing one last make-current so the non Irrlicht GL stuff can shut down properly. In my case, the ELM GLView gears example shaders and stuff needs to be deleted. So I guess the entire GL shutdown needs to be done in the render thread. Is there stuff for that yet? But other than shutdown, I've managed to move all Irrlicht calls to the evas_object_image_pixels_get_callback_set() callback. Which in theory, is called from the render thread. -- 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
