Hi Cedric, Thanks for your quick response. Sorry for my late response. Yesterday was a Korean national holiday so I got to relax a little bit. =)
I'm going to respond to some of your comments below. I'm glad that you're picking up the concerns that I have as well. In fact, I'll go ahead and start another thread with suggestions I have later. On Mon, Feb 28, 2011 at 6:44 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > Hi, > > On Mon, Feb 28, 2011 at 9:14 AM, Sung W. Park <sung...@gmail.com> 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 ! > Yes, I this will make Evas more exciting I think, even though it's pretty cool already. > > 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. > > My assumption here was just for the sake of discussion. It shows you the dirtiness/ ugliness of this solution. As you say, the whole X dependency needs to be hidden. > > - 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. > > Yes, that's exactly what I'm thinking as well. I'll propose a new sets of APIs in a new email thread. > > - 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" ? > If you look at the code for the pixmap path, there is a part where a new image object is created and hashed. It's being reference counted for multiple object reference. I just didn't think that was necessary for storing texture IDs here but I don't know enough about the image object just yet so i wanted your comments. > 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 ! > I'm glad that you were able to follow along. That will make my next email so much easier. As for changes, I guess we'll have to wait until Raster reviews them? Either way, I'm glad that there is an excitement from someone in the community. > -- > Cedric BAIL > cheers, Sung ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
