path: root/legacy/evas/src/lib/canvas/evas_gl.c
diff options
authorSung W. Park <sungwoo@gmail.com>2011-10-18 08:13:23 +0000
committerCarsten Haitzler <raster@rasterman.com>2011-10-18 08:13:23 +0000
commitc1cc0a7ed2aac046bfb684544cb46c0e41b874a5 (patch)
treec7c74e2b93cad19da65329532058707c92f86374 /legacy/evas/src/lib/canvas/evas_gl.c
parentefreet: typos (diff)
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a bug fix Here's an initial attempt at the GL extensions issue for Evas GL. I have been in discussion with a few EFL developers regarding how we should provide extensions. Essentially, there are two ways to go about doing this. 1. provide evas_gl_proc_address_get() function as it is done in other glue layers 2. provide all the extension functions in the EVAS_GL_API struct. #1 approach is how it's done in other glue layers and the driver implementor can provide new extensions easily. It is however pretty annoying to get the function prototypes right and use the function pointers and etc. #2 approach provides all the extension functions in the struct so it's definitely easier to use. Adding new extensions can be a pain as people may have to wait for new version releases. For now, we thought it was OK to just throw them in the struct as in #2 and try it out. So, I've implemented this approach. As for the extensions, I've basically included all the extensions in gl2ext.h as EvasGL currently provides all the GLES 2.0 functions. In order to display the right information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly display the supported extensions. Also, I've added a few EGL extensions that have been modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been defined as folllows. EvasGLImage (*evasglCreateImage) (int target, void* buffer, int* attrib_list); void (*evasglDestroyImage) (EvasGLImage image); const char *evas_gl_string_query() function was added to return a string of supported EvasGL extensions. So essentially, a user can search this string to see if the desired extension is supported. if it is, he can use the functions. He can always check if the function pointers are NULL as well. Take a look at the pach and let me know what you think. ______________ While I was adding the extension code, I've added a few fixes/ changes to the EvasGL. 1. glDeletBuffers bug - When I wad destroying evasgl context, I was deleting the context FBO with glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was deleting BOs in other contexts and we had some funky behaviors as a result. The bug has been fixed. 2. make_current - I've made some changes to the make current code and also added a resource context to the engine data. the resource context is used for creating surface texture/ fbos when surface/ context is created. Before, i was using evas' context but thought it'd be a good idea to use a separate context. SVN revision: 64139
Diffstat (limited to 'legacy/evas/src/lib/canvas/evas_gl.c')
1 files changed, 16 insertions, 0 deletions
diff --git a/legacy/evas/src/lib/canvas/evas_gl.c b/legacy/evas/src/lib/canvas/evas_gl.c
index 7850939e35..47bb5838ee 100644
--- a/legacy/evas/src/lib/canvas/evas_gl.c
+++ b/legacy/evas/src/lib/canvas/evas_gl.c
@@ -69,6 +69,12 @@ evas_gl_surface_create(Evas_GL *evas_gl, Evas_GL_Config *config, int width, int
return NULL;
+ if (!config)
+ {
+ ERR("Invalid Config\n");
+ return NULL;
+ }
surf = calloc(1, sizeof(Evas_GL_Surface));
surf->data = evas_gl->evas->engine.func->gl_surface_create(evas_gl->evas->engine.data.output, config, width, height);
@@ -196,6 +202,16 @@ evas_gl_make_current(Evas_GL *evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *c
return ret;
+EAPI const char *
+evas_gl_string_query(Evas_GL *evas_gl, int name)
+ return EINA_FALSE;
+ return (const char *)evas_gl->evas->engine.func->gl_string_query(evas_gl->evas->engine.data.output, name);
EAPI Evas_GL_Func
evas_gl_proc_address_get(Evas_GL *evas_gl, const char *name)