Hi, On Mon, Feb 28, 2011 at 9:14 AM, Sung W. Park <[email protected]> wrote: > My name is Sung Park and I've recently started working on a project for a > Big mobile hw company in Korea ;-) > I've been given the assignment of getting the OpenGL rendered output set as > an image object in Evas, and now I'm getting my feet wet with EFL.
That's a terribly usefull and interesting project ! Good to know you are starting to work on it ! > I'd very much appreciate your guys' help and comments. Hopefully, I'll do > the same for the community in a short period of time. > > So, here I go... > ------------------------------- > >From what I've gathered thus far, there is the > > evas_object_image_native_surface_set(..., Evas_Native_Surface *surf); > > that allows you to either pass in a pixmap or a texture id as part of the > Evas_Native_Surface structure to set it as the evas_image object source. > I've noticed that the opengl texture part of the code hasn't been > implemented yet. In fact, this is the part that we are interested in > currently: to render an image using OpenGL to an output texture (using FBO) > and then to pass that texture to the above function. > > Unfortunately, there are a few issues with this approach. (By the way, I'm > assuming that Evas is running a gl-x11 engine for the sake of discussion) Well, I dislike that assumption. We really need to have something that work whatever the backend and the environment you are running on is running. OpenGL is not linked with X except during the initialisation process. From my point of view, it's critical that we completly hide that step from Evas users. > - The main issue is that the GL application's GL context and the Evas > engine's GL context is different. Hence a texture created from the > application cannot be seen from the Evas engine's GL context and will not > output correct result. I know that in Windows or Mac, there are ways to > share texture resources even across processes, but that is not the case in > Linux environment -- you can redirect pixmaps and bind it as a texture but > not explicitly share textures. > > - However, there is a way to get around this issue. Texture resources can > be shared across different contexts by giving the share context as a > parameter when creating a new context. For example, > > glXCreateContext(Display* dpy, XVisualInfo *vis, GLXContext shareList, > Bool direct); > > the shareList can be Evas' GL context. Then when the user application > creates a GL context with this parameter, Evas will be able to see the > texture. Unfortunately, this exposes Evas' resources to the users BUT there > isn't really a reasonably better option without writing a ton code... > > However, explicitly exposing Evas' GL context just sound like a really > really bad idea. One option that I would like to discuss over in a separate > thread is possibly having evas provide a set of open gl glue layer apis and > take care of the creating context and etc. for the users so they don't have > to explicitly deal with Evas' internals. I do agree that we should never expose Evas GL context or we will end in very deep trouble. I don't know if that's possible at all, but maybe we could let Evas create and provide a GL context that is correctly setup to share the texture created with it. Something that an upper library could reuse directly without taking care of the backend at all. > - There's also the make_current overhead for dynamic scenes since the > application and evas has to call make_current every time they render. I'll > address that again next time. Ok, but don't forget that it would be nice if we don't expose the link with X/Linux at all. > ----------------------------------------------- > > For this thread, I would like to ask the community to review > evas_object_image_native_surface_set portion of the code that I've added. > The patch that I'm including is for gl_x11 engine evas_engine.c and > gl_common's evas_gl_context.c. I'm also including a simple sample program > that tests the code. consider the code a minor fix that allows the sample > code to run and maybe you guys can help out completing it. > > By the way, It's been quite difficult trying to figure out the semantics of > some of the evas_object_image functions without proper documentations... so > i may have gotten certain things wrong here.. > > Also, if you look at the sample code, I've used glXGetCurrentContext() to > grab Evas' current GL context to use it as a share context. It's a dirty > trick but it allows me to test the code for now =) After looking at your example, it's definitivly dirty :-) But that make my point, we should hide the creation of that "child" GL context. Same goes for make current in my opinion. Maybe that would require the addition of two new API to Evas, but that would make it work for all engine. I do like the fact that you keep your change really small, that's good ! > I've also noticed that there was a y-invert texture coordinate bug (GL and > evas has different coordinate system) so I've made those changes in > evas_gl_context.c Hum, that sounds like a bug that we should fix right now, before waiting for the rest of your patch to go in. Sadly I don't know enought about GL engine internal to be sure about it. I fear only raster has the knowledge about that part to apply it safely. > ___________________________ > Here are some comments about the changes I've made. > > When using the image object, one would set the data using > > evas_object_image_data_set(obj, data); > > and internally, this creates a Evas_GL_Image structure. If I don't use the > above function, it doesn't create a Evas_GL_Image object. > For setting a native surface opengl texture, I figured it's not necessary to > call above function so i've added some code in the beginning of the > native_set() that creates the object if it's an OpenGL Native Surface. > > Also, I didn't think it was necessary to hash the image object so i didn't > add the code in there but I could be wrong I guess. Sorry but what do you mean by "hash the image object" ? > Finally, I think it may not be a bad idea to add target (texture target) > field in the Evas_Native_Surface but I guess that can be debated. For now, > i've just hard-coded the field with GL_TEXTURE_2D. > > Sorry for the long email. Hehe, it was quite informative and make the review of your patch quite easy for me. Keep it like that ! -- Cedric BAIL ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
