On Mon, 28 Feb 2011 17:14:58 +0900 "Sung W. Park" <sung...@gmail.com> said:
> Hi all, > > My name is Sung Park and I've recently started working on a project for a > Big mobile hw company in Korea ;-) oh out with it already! :) everyone knows its samsung. :) > 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. slosh slosh. welcome to our little corner of the swamp :) > 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) > > - 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. > > - 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. actually i suspect we'll have to accept that there will always be some overhead in this whole gl on top of evas thing compared to gl directly in a window/buffer/fb yourself, so i don't think it will be TOO bad. > ----------------------------------------------- > > 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 =) > > 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 > > ___________________________ > 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. > > 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. > > Your comments on the patches would be very much appreciated. comments here: :) evas_gl_context.patch: yup! in. i just never handled the y invert case (or lets say.. the non-inverted case). i just never encountered it so i n gl_x11_evas_engine.patch: surprisingly... i have very little to grumble about. the only thing is the hash thing where you comments "i didn't think it was necessary...". as such you can get away with not doing it until you try and duplicate the same texture in multiple image objects. the compositor does this - or can do it (and it is used for some effects like exposee). this means it will share the same gl image wrapper struct etc. etc. which saves some resources. what you need to do here is put the image in a hash - like the one that uses pixmap id, but here using texture id. so u'll need another native_hash so that id's dont clash (tex id vs pixmap id) and then put it in there and take it out of it just like the native_hash stuff is done for pixmap id's. :) now as for target GL_TEXTURE_2D ... vs what? GL_TEXTURE_RECTANGLE_NV/ARB etc.? i'm not sure that's entirely wise? 1D and 3D textures would need proper handling then too. also rectangle textures are subject to a different coordinate space (in pixels vs 0.0 -> 1.0). right now the gl engine core doesn't use/handle these at all actually. i'm not entirely sure we need to/should as rectangle textures come with a whole bunch of gotchas/limitations, and there are standard npot textures around anyway. :) i'm not really sure any client would need/want to do this? so if you can fix the hash thing... that'd be good. the yinvert patch is already in svn, so just send an update on the other stuff as above :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
