Ah, i see that you finally had a chance to go through your email piles =) welcome back!
On Thu, Mar 10, 2011 at 5:52 PM, Carsten Haitzler <ras...@rasterman.com>wrote: > 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. :) > ok, i didn't say it =P > > > 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. > i agree. > > > ----------------------------------------------- > > > > 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. :) > my thoughts were that it wouldn't be a big overhead to just create new image objects for each texture reference but you're right in that it does save resources if you reference them. by the way, is there a good way to create a unique ID that i can use for hashing? since pixmap IDs are globally unique, it's good to use it as hash keys but I think using texture IDs would be a bad idea since it's context specific. any thoughts on that? > > 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? > the thought of having texture target came after seeing #ifdef GL_TEXTURE_RECTANGLE_ARB in the code. If you tell the user that evas_object_image_native_surface_set only supports GL_TEXTURE_2D then I guess not having it would be fine. > 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 :) > > I'll do that once I get your response about the hash id. > -- > ------------- 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
