Hi all, 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.
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.
-----------------------------------------------
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.
cheers,
Sung
native_surface_set.tgz
Description: GNU Zip compressed data
------------------------------------------------------------------------------ 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
