enlightenment/efl
enlightenment
/
efl
8
7
Fork 14
Code Issues 13 Pull Requests 3 Projects Releases Wiki Activity
efl/legacy/evas/src/modules/engines/gl_x11/evas_engine.c

4413 lines
136 KiB
C
Raw Normal View History

Evas: Changing the font engine to work with Eina_Unicode instead of utf8. Changing textblock and text objects to work with Eina_Unicode instead of utf8 (internally, API remains intact). Started relying on new fribidi 0.19.2 instead of the old fribidi. A lot of fixes to the font engine. Renaming of evas_common_font_utf8_* to evas_common_encoding_utf8_* This relies on new Eina changes and types: Eina_Unicode, Eina_UStrbuf and Eina_UStringshare. SVN revision: 50595
2010-07-28 05:00:41 -07:00
#include "evas_common.h" /* Also includes international specific stuff */
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
#include "evas_engine.h"
Evas: Check for dlsym and disable gl engines if not found SVN revision: 64091
2011-10-15 02:31:04 -07:00
#ifdef HAVE_DLSYM
# include <dlfcn.h> /* dlopen,dlclose,etc */
#else
# error gl_x11 should not get compiled if dlsym is not found on the system!
#endif
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#define EVAS_GL_NO_GL_H_CHECK 1
#include "Evas_GL.h"
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
// EGL / GLES
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
# if defined(GLES_VARIETY_S3C6410)
# elif defined(GLES_VARIETY_SGX)
# endif
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#else
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
// GLX
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
typedef struct _Render_Engine Render_Engine;
typedef struct _Render_Engine_GL_Surface Render_Engine_GL_Surface;
typedef struct _Render_Engine_GL_Context Render_Engine_GL_Context;
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
2011-10-18 01:13:23 -07:00
typedef struct _Render_Engine_GL_Resource Render_Engine_GL_Resource;
typedef struct _Extension_Entry Extension_Entry;
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
struct _Render_Engine
{
Evas_GL_X11_Window *win;
Evas_Engine_Info_GL_X11 *info;
Evas *evas;
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
Tilebuf *tb;
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
int end;
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
/*
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
XrmDatabase xrdb; // xres - dpi
struct { // xres - dpi
int dpi; // xres - dpi
} xr; // xres - dpi
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
*/
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
int w, h;
only set swap interval if it changes for egl - and dont waitgl if swap native is available. SVN revision: 53849
2010-10-25 00:22:43 -07:00
int vsync;
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
2011-10-18 01:13:23 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Shader used for Evas_GL_Direct Optimization
GLuint df_program;
GLuint df_vtx_shader;
GLuint df_fgmt_shader;
GLuint df_col_attrib;
GLuint df_pos_attrib;
GLfloat df_clear_color[4];
GLfloat df_depth_value;
int df_initialized;
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
};
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
struct _Render_Engine_GL_Surface
{
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
2011-10-18 01:13:23 -07:00
int initialized;
int fbo_attached;
int w, h;
int depth_bits;
int stencil_bits;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
int direct_fb_opt;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
// Render target texture/buffers
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
2011-10-18 01:13:23 -07:00
GLuint rt_tex;
GLint rt_internal_fmt;
GLenum rt_fmt;
GLuint rb_depth;
GLenum rb_depth_fmt;
GLuint rb_stencil;
GLenum rb_stencil_fmt;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
EGLSurface direct_sfc;
#else
Window direct_sfc;
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Render_Engine_GL_Context *current_ctx;
};
struct _Render_Engine_GL_Context
{
int initialized;
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
EGLContext context;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#else
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
GLXContext context;
#endif
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
GLuint context_fbo;
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
GLuint current_fbo;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
int scissor_enabled;
int scissor_upated;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Render_Engine_GL_Surface *current_sfc;
};
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
2011-10-18 01:13:23 -07:00
// Resources used per thread
struct _Render_Engine_GL_Resource
{
// Resource context/surface per Thread in TLS for evasgl use
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
EGLContext context;
EGLSurface surface;
#else
GLXContext context;
#endif
};
// Extension Handling
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
struct _Extension_Entry
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
2011-10-18 01:13:23 -07:00
{
const char *name;
const char *real_name;
int supported;
};
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
static int initted = 0;
static int gl_wins = 0;
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
static int gl_direct_override = 0;
static int gl_direct_enabled = 0;
static Render_Engine_GL_Context *current_evgl_ctx = NULL;
static Render_Engine *current_engine = NULL;
static Evas_Object *gl_direct_img_obj = NULL;
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
2011-10-18 01:13:23 -07:00
static char _gl_ext_string[1024];
static char _evasgl_ext_string[1024];
// Resource context/surface per Thread in TLS for evasgl use
static Eina_TLS resource_key;
static Eina_List *resource_list;
LK(resource_lock);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
typedef void (*_eng_fn) (void);
typedef _eng_fn (*glsym_func_eng_fn) ();
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
2011-10-18 01:13:23 -07:00
typedef void (*glsym_func_void) ();
typedef void *(*glsym_func_void_ptr) ();
typedef int (*glsym_func_int) ();
typedef unsigned int (*glsym_func_uint) ();
typedef unsigned char (*glsym_func_uchar) ();
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
typedef unsigned char *(*glsym_func_uchar_ptr) ();
typedef const char *(*glsym_func_const_char_ptr) ();
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
gles - update on t2pixmap SVN revision: 45681
2010-01-28 21:32:51 -08:00
#ifndef EGL_NATIVE_PIXMAP_KHR
# define EGL_NATIVE_PIXMAP_KHR 0x30b0
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
_eng_fn (*glsym_eglGetProcAddress) (const char *a) = NULL;
void (*glsym_eglBindTexImage) (EGLDisplay a, EGLSurface b, int c) = NULL;
void (*glsym_eglReleaseTexImage) (EGLDisplay a, EGLSurface b, int c) = NULL;
void *(*glsym_eglCreateImage) (EGLDisplay a, EGLContext b, EGLenum c, EGLClientBuffer d, const int *e) = NULL;
void (*glsym_eglDestroyImage) (EGLDisplay a, void *b) = NULL;
void (*glsym_glEGLImageTargetTexture2DOES) (int a, void *b) = NULL;
void (*glsym_glEGLImageTargetRenderbufferStorageOES) (int a, void *b) = NULL;
void *(*glsym_eglMapImageSEC) (void *a, void *b) = NULL;
unsigned int (*glsym_eglUnmapImageSEC) (void *a, void *b) = NULL;
const char *(*glsym_eglQueryString) (EGLDisplay a, int name) = NULL;
unsigned int (*glsym_eglLockSurface) (EGLDisplay a, EGLSurface b, const int *attrib_list) = NULL;
unsigned int (*glsym_eglUnlockSurface) (EGLDisplay a, EGLSurface b) = NULL;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
#else
typedef XID (*glsym_func_xid) ();
_eng_fn (*glsym_glXGetProcAddress) (const char *a) = NULL;
void (*glsym_glXBindTexImage) (Display *a, GLXDrawable b, int c, int *d) = NULL;
void (*glsym_glXReleaseTexImage) (Display *a, GLXDrawable b, int c) = NULL;
int (*glsym_glXGetVideoSync) (unsigned int *a) = NULL;
int (*glsym_glXWaitVideoSync) (int a, int b, unsigned int *c) = NULL;
XID (*glsym_glXCreatePixmap) (Display *a, void *b, Pixmap c, const int *d) = NULL;
void (*glsym_glXDestroyPixmap) (Display *a, XID b) = NULL;
void (*glsym_glXQueryDrawable) (Display *a, XID b, int c, unsigned int *d) = NULL;
int (*glsym_glXSwapIntervalSGI) (int a) = NULL;
void (*glsym_glXSwapIntervalEXT) (Display *s, GLXDrawable b, int c) = NULL;
const char *(*glsym_glXQueryExtensionsString) (Display *a, int screen) = NULL;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#endif
fix calloc with negative values - missing size set initially! SVN revision: 46701
2010-03-01 07:51:22 -08:00
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
2011-10-18 01:13:23 -07:00
// GLES2 Extensions
void (*glsym_glGetProgramBinaryOES) (GLuint program, GLsizei bufSize, GLsizei *length, GLenum *binaryFormat, void *binary) = NULL;
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
void (*glsym_glProgramBinaryOES) (GLuint program, GLenum binaryFormat, const void *binary, GLint length) = NULL;
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
2011-10-18 01:13:23 -07:00
void* (*glsym_glMapBufferOES) (GLenum target, GLenum access) = NULL;
unsigned char (*glsym_glUnmapBufferOES) (GLenum target) = NULL;
void (*glsym_glGetBufferPointervOES) (GLenum target, GLenum pname, void** params) = NULL;
void (*glsym_glTexImage3DOES) (GLenum target, GLint level, GLenum internalformat, GLsizei width, GLsizei height, GLsizei depth, GLint border, GLenum format, GLenum type, const void* pixels) = NULL;
void (*glsym_glTexSubImage3DOES) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei height, GLsizei depth, GLenum format, GLenum type, const void* pixels) = NULL;
void (*glsym_glCopyTexSubImage3DOES) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLint x, GLint y, GLsizei width, GLsizei height) = NULL;
void (*glsym_glCompressedTexImage3DOES) (GLenum target, GLint level, GLenum internalformat, GLsizei width, GLsizei height, GLsizei depth, GLint border, GLsizei imageSize, const void* data) = NULL;
void (*glsym_glCompressedTexSubImage3DOES) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei height, GLsizei depth, GLenum format, GLsizei imageSize, const void* data) = NULL;
void (*glsym_glFramebufferTexture3DOES) (GLenum target, GLenum attachment, GLenum textarget, GLuint texture, GLint level, GLint zoffset) = NULL;
void (*glsym_glGetPerfMonitorGroupsAMD) (GLint* numGroups, GLsizei groupsSize, GLuint* groups) = NULL;
void (*glsym_glGetPerfMonitorCountersAMD) (GLuint group, GLint* numCounters, GLint* maxActiveCounters, GLsizei counterSize, GLuint* counters) = NULL;
void (*glsym_glGetPerfMonitorGroupStringAMD) (GLuint group, GLsizei bufSize, GLsizei* length, char* groupString) = NULL;
void (*glsym_glGetPerfMonitorCounterStringAMD) (GLuint group, GLuint counter, GLsizei bufSize, GLsizei* length, char* counterString) = NULL;
void (*glsym_glGetPerfMonitorCounterInfoAMD) (GLuint group, GLuint counter, GLenum pname, void* data) = NULL;
void (*glsym_glGenPerfMonitorsAMD) (GLsizei n, GLuint* monitors) = NULL;
void (*glsym_glDeletePerfMonitorsAMD) (GLsizei n, GLuint* monitors) = NULL;
void (*glsym_glSelectPerfMonitorCountersAMD) (GLuint monitor, GLboolean enable, GLuint group, GLint numCounters, GLuint* countersList) = NULL;
void (*glsym_glBeginPerfMonitorAMD) (GLuint monitor) = NULL;
void (*glsym_glEndPerfMonitorAMD) (GLuint monitor) = NULL;
void (*glsym_glGetPerfMonitorCounterDataAMD) (GLuint monitor, GLenum pname, GLsizei dataSize, GLuint* data, GLint* bytesWritten) = NULL;
void (*glsym_glDiscardFramebufferEXT) (GLenum target, GLsizei numAttachments, const GLenum* attachments) = NULL;
void (*glsym_glMultiDrawArraysEXT) (GLenum mode, GLint* first, GLsizei* count, GLsizei primcount) = NULL;
void (*glsym_glMultiDrawElementsEXT) (GLenum mode, const GLsizei* count, GLenum type, const GLvoid** indices, GLsizei primcount) = NULL;
void (*glsym_glDeleteFencesNV) (GLsizei n, const GLuint* fences) = NULL;
void (*glsym_glGenFencesNV) (GLsizei n, GLuint* fences) = NULL;
unsigned char (*glsym_glIsFenceNV) (GLuint fence) = NULL;
unsigned char (*glsym_glTestFenceNV) (GLuint fence) = NULL;
void (*glsym_glGetFenceivNV) (GLuint fence, GLenum pname, GLint* params) = NULL;
void (*glsym_glFinishFenceNV) (GLuint fence) = NULL;
void (*glsym_glSetFenceNV) (GLuint, GLenum) = NULL;
void (*glsym_glGetDriverControlsQCOM) (GLint* num, GLsizei size, GLuint* driverControls) = NULL;
void (*glsym_glGetDriverControlStringQCOM) (GLuint driverControl, GLsizei bufSize, GLsizei* length, char* driverControlString) = NULL;
void (*glsym_glEnableDriverControlQCOM) (GLuint driverControl) = NULL;
void (*glsym_glDisableDriverControlQCOM) (GLuint driverControl) = NULL;
void (*glsym_glExtGetTexturesQCOM) (GLuint* textures, GLint maxTextures, GLint* numTextures) = NULL;
void (*glsym_glExtGetBuffersQCOM) (GLuint* buffers, GLint maxBuffers, GLint* numBuffers) = NULL;
void (*glsym_glExtGetRenderbuffersQCOM) (GLuint* renderbuffers, GLint maxRenderbuffers, GLint* numRenderbuffers) = NULL;
void (*glsym_glExtGetFramebuffersQCOM) (GLuint* framebuffers, GLint maxFramebuffers, GLint* numFramebuffers) = NULL;
void (*glsym_glExtGetTexLevelParameterivQCOM) (GLuint texture, GLenum face, GLint level, GLenum pname, GLint* params) = NULL;
void (*glsym_glExtTexObjectStateOverrideiQCOM) (GLenum target, GLenum pname, GLint param) = NULL;
void (*glsym_glExtGetTexSubImageQCOM) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei height, GLsizei depth, GLenum format, GLenum type, void* texels) = NULL;
void (*glsym_glExtGetBufferPointervQCOM) (GLenum target, void** params) = NULL;
void (*glsym_glExtGetShadersQCOM) (GLuint* shaders, GLint maxShaders, GLint* numShaders) = NULL;
void (*glsym_glExtGetProgramsQCOM) (GLuint* programs, GLint maxPrograms, GLint* numPrograms) = NULL;
unsigned char (*glsym_glExtIsProgramBinaryQCOM) (GLuint program) = NULL;
void (*glsym_glExtGetProgramBinarySourceQCOM) (GLuint program, GLenum shadertype, char* source, GLint* length) = NULL;
//------ GLES 2.0 Extensions supported in EvasGL -----//
static Extension_Entry _gl_ext_entries[] = {
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
//--- Function Extensions ---//
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
2011-10-18 01:13:23 -07:00
{ "GL_OES_get_program_binary", "get_program_binary", 0 },
{ "GL_OES_mapbuffer", "mapbuffer", 0 },
{ "GL_OES_texture_3D", "texture_3D", 0 },
{ "AMD_performance_monitor", "AMD_performance_monitor", 0 },
{ "GL_EXT_discard_framebuffer", "discard_framebuffer", 0 },
{ "GL_EXT_multi_draw_arrays", "multi_draw_arrays", 0 },
{ "GL_NV_fence", "NV_fence", 0 },
{ "GL_QCOM_driver_control", "QCOM_driver_control", 0 },
{ "GL_QCOM_extended_get", "QCOM_extended_get", 0 },
{ "GL_QCOM_extended_get2", "QCOM_extended_get2", 0 },
//--- Define Extensions ---//
{ "GL_OES_compressed_ETC1_RGB8_texture", "compressed_ETC1_RGB8_texture", 0 },
{ "GL_OES_compressed_paletted_texture", "compressed_paletted_texture", 0 },
{ "GL_OES_depth24", "depth24", 0 },
{ "GL_OES_depth32", "depth32", 0 },
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_OES_EvasGL_image", "EGL_image", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_OES_packed_depth_stencil", "packed_depth_stencil", 0 },
{ "GL_OES_rgb8_rgba8", "rgb8_rgba8", 0 },
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_OES_standard_derivatives", "standard_derivatives", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_OES_stencil1", "stencil1", 0 },
{ "GL_OES_stencil4", "stencil4", 0 },
{ "GL_OES_texture_float", "texture_float", 0 },
{ "GL_OES_texture_half_float", "texture_half_float", 0 },
{ "GL_OES_texture_half_float_linear", "texture_half_float_linear", 0 },
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_OES_texture_npot", "texture_npot", 0 },
{ "GL_OES_vertex_half_float", "vertex_half_float", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_OES_vertex_type_10_10_10_2", "vertex_type_10_10_10_2", 0 },
{ "GL_AMD_compressed_3DC_texture", "compressed_3DC_texture", 0 },
{ "GL_AMD_compressed_ATC_texture", "compressed_ATC_texture", 0 },
{ "GL_AMD_program_binary_Z400", "program_binary_Z400", 0 },
{ "GL_EXT_blend_minmax", "blend_minmax", 0 },
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_EXT_read_format_bgra", "read_format_bgra", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_EXT_texture_filter_anisotropic", "texture_filter_anisotrophic", 0 },
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_EXT_texture_format_BGRA8888", "texture_format_BGRA8888", 0 },
{ "GL_EXT_texture_type_2_10_10_10_REV", "texture_type_2_10_10_10_rev", 0 },
{ "GL_IMG_program_binary", "IMG_program_binary", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_IMG_read_format", "IMG_read_format", 0 },
{ "GL_IMG_shader_binary", "IMG_shader_binary", 0 },
{ "GL_IMG_texture_compression_pvrtc", "IMG_texture_compression_pvrtc", 0 },
{ "GL_QCOM_perfmon_global_mode", "QCOM_perfmon_global_mode", 0 },
{ "GL_QCOM_writeonly_rendering", "QCOM_writeonly_rendering", 0 },
#else
//--- Function Extensions ---//
{ "GL_OES_get_program_binary", "get_program_binary", 0 },
{ "GL_OES_mapbuffer", "mapbuffer", 0 },
{ "GL_OES_texture_3D", "texture_3D", 0 },
{ "AMD_performance_monitor", "AMD_performance_monitor", 0 },
{ "GL_EXT_discard_framebuffer", "discard_framebuffer", 0 },
{ "GL_EXT_multi_draw_arrays", "multi_draw_arrays", 0 },
{ "GL_NV_fence", "NV_fence", 0 },
{ "GL_QCOM_driver_control", "QCOM_driver_control", 0 },
{ "GL_QCOM_extended_get", "QCOM_extended_get", 0 },
{ "GL_QCOM_extended_get2", "QCOM_extended_get2", 0 },
//--- Define Extensions ---//
{ "GL_OES_compressed_ETC1_RGB8_texture", "compressed_ETC1_RGB8_texture", 0 },
{ "GL_OES_compressed_paletted_texture", "compressed_paletted_texture", 0 },
{ "GL_OES_depth24", "depth24", 0 },
{ "GL_OES_depth32", "depth32", 0 },
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_OES_EvasGL_image", "EGL_image", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_OES_packed_depth_stencil", "packed_depth_stencil", 0 },
{ "GL_OES_rgb8_rgba8", "rgb8_rgba8", 0 },
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_OES_standard_derivatives", "standard_derivatives", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_OES_stencil1", "stencil1", 0 },
{ "GL_OES_stencil4", "stencil4", 0 },
{ "GL_OES_texture_float", "texture_float", 0 },
{ "GL_OES_texture_half_float", "texture_half_float", 0 },
{ "GL_OES_texture_half_float_linear", "texture_half_float_linear", 0 },
{ "GL_OES_texture_npot", "texture_non_power_of_two", 0 }, // Desktop differs
{ "GL_OES_vertex_half_float", "half_float_vertex", 0 }, // Desktop differs
{ "GL_OES_vertex_type_10_10_10_2", "vertex_type_10_10_10_2", 0 },
{ "GL_AMD_compressed_3DC_texture", "compressed_3DC_texture", 0 },
{ "GL_AMD_compressed_ATC_texture", "compressed_ATC_texture", 0 },
{ "GL_AMD_program_binary_Z400", "program_binary_Z400", 0 },
{ "GL_EXT_blend_minmax", "blend_minmax", 0 },
{ "GL_EXT_read_format_bgra", "bgra", 0 }, // Desktop differs
{ "GL_EXT_texture_filter_anisotropic", "texture_filter_anisotrophic", 0 },
{ "GL_EXT_texture_format_BGRA8888", "bgra", 0 }, // Desktop differs
{ "GL_EXT_texture_type_2_10_10_10_REV", "vertex_type_2_10_10_10_rev", 0 }, // Desktop differs ???
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{ "GL_IMG_program_binary", "IMG_program_binary", 0 },
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
2011-10-18 01:13:23 -07:00
{ "GL_IMG_read_format", "IMG_read_format", 0 },
{ "GL_IMG_shader_binary", "IMG_shader_binary", 0 },
{ "GL_IMG_texture_compression_pvrtc", "IMG_texture_compression_pvrtc", 0 },
{ "GL_QCOM_perfmon_global_mode", "QCOM_perfmon_global_mode", 0 },
{ "GL_QCOM_writeonly_rendering", "QCOM_writeonly_rendering", 0 },
#endif
{ NULL, NULL, 0}
};
//------ Extensions supported in EvasGL -----//
static Extension_Entry _evasgl_ext_entries[] = {
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
{ "EvasGL_KHR_image", "EGL_KHR_image", 0 },
{ "EvasGL_KHR_vg_parent_image", "EGL_KHR_vg_parent_image", 0 },
{ "EvasGL_KHR_gl_texture_2D_image", "EGL_KHR_gl_texture_2D_image", 0 },
{ "EvasGL_KHR_gl_texture_cubemap_image", "EGL_KHR_gl_texture_cubemap_image", 0 },
{ "EvasGL_KHR_gl_texture_3D_image", "EGL_KHR_gl_texture_3D_image", 0 },
{ "EvasGL_KHR_gl_renderbuffer_image", "EGL_KHR_gl_renderbuffer_image", 0 },
#else
#endif
{ NULL, NULL, 0 }
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
};
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
2011-10-18 01:13:23 -07:00
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
static void
_sym_init(void)
{
static int done = 0;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
if (done) return;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
fix gl stride SVN revision: 52432
2010-09-18 17:28:58 -07:00
#define FINDSYM(dst, sym, typ) \
if ((!dst) && (glsym_eglGetProcAddress)) dst = (typ)glsym_eglGetProcAddress(sym); \
if (!dst) dst = (typ)dlsym(RTLD_DEFAULT, sym)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
FINDSYM(glsym_eglGetProcAddress, "eglGetProcAddress", glsym_func_eng_fn);
FINDSYM(glsym_eglGetProcAddress, "eglGetProcAddressEXT", glsym_func_eng_fn);
FINDSYM(glsym_eglGetProcAddress, "eglGetProcAddressARB", glsym_func_eng_fn);
FINDSYM(glsym_eglGetProcAddress, "eglGetProcAddressKHR", glsym_func_eng_fn);
FINDSYM(glsym_eglBindTexImage, "eglBindTexImage", glsym_func_void);
FINDSYM(glsym_eglBindTexImage, "eglBindTexImageEXT", glsym_func_void);
FINDSYM(glsym_eglBindTexImage, "eglBindTexImageARB", glsym_func_void);
FINDSYM(glsym_eglBindTexImage, "eglBindTexImageKHR", glsym_func_void);
FINDSYM(glsym_eglReleaseTexImage, "eglReleaseTexImage", glsym_func_void);
FINDSYM(glsym_eglReleaseTexImage, "eglReleaseTexImageEXT", glsym_func_void);
FINDSYM(glsym_eglReleaseTexImage, "eglReleaseTexImageARB", glsym_func_void);
FINDSYM(glsym_eglReleaseTexImage, "eglReleaseTexImageKHR", glsym_func_void);
FINDSYM(glsym_eglCreateImage, "eglCreateImage", glsym_func_void_ptr);
FINDSYM(glsym_eglCreateImage, "eglCreateImageEXT", glsym_func_void_ptr);
FINDSYM(glsym_eglCreateImage, "eglCreateImageARB", glsym_func_void_ptr);
FINDSYM(glsym_eglCreateImage, "eglCreateImageKHR", glsym_func_void_ptr);
FINDSYM(glsym_eglDestroyImage, "eglDestroyImage", glsym_func_void);
FINDSYM(glsym_eglDestroyImage, "eglDestroyImageEXT", glsym_func_void);
FINDSYM(glsym_eglDestroyImage, "eglDestroyImageARB", glsym_func_void);
FINDSYM(glsym_eglDestroyImage, "eglDestroyImageKHR", glsym_func_void);
FINDSYM(glsym_glEGLImageTargetTexture2DOES, "glEGLImageTargetTexture2DOES", glsym_func_void);
FINDSYM(glsym_glEGLImageTargetRenderbufferStorageOES, "glEGLImageTargetRenderbufferStorageOES", glsym_func_void);
FINDSYM(glsym_eglMapImageSEC, "eglMapImageSEC", glsym_func_void_ptr);
FINDSYM(glsym_eglUnmapImageSEC, "eglUnmapImageSEC", glsym_func_uint);
FINDSYM(glsym_eglQueryString, "eglQueryString", glsym_func_const_char_ptr);
FINDSYM(glsym_eglLockSurface, "eglLockSurface", glsym_func_uint);
FINDSYM(glsym_eglLockSurface, "eglLockSurfaceEXT", glsym_func_uint);
FINDSYM(glsym_eglLockSurface, "eglLockSurfaceARB", glsym_func_uint);
FINDSYM(glsym_eglLockSurface, "eglLockSurfaceKHR", glsym_func_uint);
FINDSYM(glsym_eglUnlockSurface, "eglUnlockSurface", glsym_func_uint);
FINDSYM(glsym_eglUnlockSurface, "eglUnlockSurfaceEXT", glsym_func_uint);
FINDSYM(glsym_eglUnlockSurface, "eglUnlockSurfaceARB", glsym_func_uint);
FINDSYM(glsym_eglUnlockSurface, "eglUnlockSurfaceKHR", glsym_func_uint);
cedric's cache changes patch SVN revision: 34253
2008-04-11 17:32:30 -07:00
#else
fix gl stride SVN revision: 52432
2010-09-18 17:28:58 -07:00
#define FINDSYM(dst, sym, typ) \
if ((!dst) && (glsym_glXGetProcAddress)) dst = (typ)glsym_glXGetProcAddress(sym); \
if (!dst) dst = (typ)dlsym(RTLD_DEFAULT, sym)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
FINDSYM(glsym_glXGetProcAddress, "glXGetProcAddress", glsym_func_eng_fn);
FINDSYM(glsym_glXGetProcAddress, "glXGetProcAddressEXT", glsym_func_eng_fn);
FINDSYM(glsym_glXGetProcAddress, "glXGetProcAddressARB", glsym_func_eng_fn);
FINDSYM(glsym_glXBindTexImage, "glXBindTexImage", glsym_func_void);
FINDSYM(glsym_glXBindTexImage, "glXBindTexImageEXT", glsym_func_void);
FINDSYM(glsym_glXBindTexImage, "glXBindTexImageARB", glsym_func_void);
FINDSYM(glsym_glXReleaseTexImage, "glXReleaseTexImage", glsym_func_void);
FINDSYM(glsym_glXReleaseTexImage, "glXReleaseTexImageEXT", glsym_func_void);
FINDSYM(glsym_glXReleaseTexImage, "glXReleaseTexImageARB", glsym_func_void);
FINDSYM(glsym_glXGetVideoSync, "glXGetVideoSyncSGI", glsym_func_int);
FINDSYM(glsym_glXWaitVideoSync, "glXWaitVideoSyncSGI", glsym_func_int);
FINDSYM(glsym_glXCreatePixmap, "glXCreatePixmap", glsym_func_xid);
FINDSYM(glsym_glXCreatePixmap, "glXCreatePixmapEXT", glsym_func_xid);
FINDSYM(glsym_glXCreatePixmap, "glXCreatePixmapARB", glsym_func_xid);
FINDSYM(glsym_glXDestroyPixmap, "glXDestroyPixmap", glsym_func_void);
FINDSYM(glsym_glXDestroyPixmap, "glXDestroyPixmapEXT", glsym_func_void);
FINDSYM(glsym_glXDestroyPixmap, "glXDestroyPixmapARB", glsym_func_void);
FINDSYM(glsym_glXQueryDrawable, "glXQueryDrawable", glsym_func_void);
FINDSYM(glsym_glXQueryDrawable, "glXQueryDrawableEXT", glsym_func_void);
FINDSYM(glsym_glXQueryDrawable, "glXQueryDrawableARB", glsym_func_void);
FINDSYM(glsym_glXSwapIntervalSGI, "glXSwapIntervalMESA", glsym_func_int);
FINDSYM(glsym_glXSwapIntervalSGI, "glXSwapIntervalSGI", glsym_func_int);
FINDSYM(glsym_glXSwapIntervalEXT, "glXSwapIntervalEXT", glsym_func_void);
FINDSYM(glsym_glXQueryExtensionsString, "glXQueryExtensionsString", glsym_func_const_char_ptr);
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
2011-10-18 01:13:23 -07:00
#endif
//----------- GLES 2.0 Extensions ------------//
// If the symbol's not found, they get set to NULL
// If one of the functions in the extension exists, the extension in supported
/* GL_OES_get_program_binary */
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinary", glsym_func_void);
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinaryEXT", glsym_func_void);
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinaryARB", glsym_func_void);
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinaryOES", glsym_func_void);
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinary", glsym_func_void);
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinaryEXT", glsym_func_void);
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinaryARB", glsym_func_void);
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinaryOES", glsym_func_void);
// Check the first function to see if the extension is supported...
if (glsym_glGetProgramBinaryOES) _gl_ext_entries[0].supported = 1;
/* GL_OES_mapbuffer */
FINDSYM(glsym_glMapBufferOES, "glMapBuffer", glsym_func_void_ptr);
FINDSYM(glsym_glMapBufferOES, "glMapBufferEXT", glsym_func_void_ptr);
FINDSYM(glsym_glMapBufferOES, "glMapBufferARB", glsym_func_void_ptr);
FINDSYM(glsym_glMapBufferOES, "glMapBufferOES", glsym_func_void_ptr);
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBuffer", glsym_func_uchar);
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBufferEXT", glsym_func_uchar);
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBufferARB", glsym_func_uchar);
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBufferOES", glsym_func_uchar);
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointerv", glsym_func_void);
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointervEXT", glsym_func_void);
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointervARB", glsym_func_void);
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointervOES", glsym_func_void);
if (glsym_glMapBufferOES) _gl_ext_entries[1].supported = 1;
/* GL_OES_texture_3D */
FINDSYM(glsym_glTexImage3DOES, "glTexImage3D", glsym_func_void);
FINDSYM(glsym_glTexImage3DOES, "glTexImage3DEXT", glsym_func_void);
FINDSYM(glsym_glTexImage3DOES, "glTexImage3DARB", glsym_func_void);
FINDSYM(glsym_glTexImage3DOES, "glTexImage3DOES", glsym_func_void);
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3D", glsym_func_void);
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3DEXT", glsym_func_void);
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3DARB", glsym_func_void);
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3DOES", glsym_func_void);
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3D", glsym_func_void);
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3DARB", glsym_func_void);
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3DEXT", glsym_func_void);
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3DOES", glsym_func_void);
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3D", glsym_func_void);
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3DARB", glsym_func_void);
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3DEXT", glsym_func_void);
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3DOES", glsym_func_void);
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3D", glsym_func_void);
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3DARB", glsym_func_void);
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3DEXT", glsym_func_void);
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3DOES", glsym_func_void);
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3D", glsym_func_void);
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3DARB", glsym_func_void);
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3DEXT", glsym_func_void);
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3DOES", glsym_func_void);
if (glsym_glTexSubImage3DOES) _gl_ext_entries[2].supported = 1;
/* AMD_performance_monitor */
FINDSYM(glsym_glGetPerfMonitorGroupsAMD, "glGetPerfMonitorGroupsAMD", glsym_func_void);
FINDSYM(glsym_glGetPerfMonitorCountersAMD, "glGetPerfMonitorCountersAMD", glsym_func_void);
FINDSYM(glsym_glGetPerfMonitorGroupStringAMD, "glGetPerfMonitorGroupStringAMD", glsym_func_void);
FINDSYM(glsym_glGetPerfMonitorCounterStringAMD, "glGetPerfMonitorCounterStringAMD", glsym_func_void);
FINDSYM(glsym_glGetPerfMonitorCounterInfoAMD, "glGetPerfMonitorCounterInfoAMD", glsym_func_void);
FINDSYM(glsym_glGenPerfMonitorsAMD, "glGenPerfMonitorsAMD", glsym_func_void);
FINDSYM(glsym_glDeletePerfMonitorsAMD, "glDeletePerfMonitorsAMD", glsym_func_void);
FINDSYM(glsym_glSelectPerfMonitorCountersAMD, "glSelectPerfMonitorCountersAMD", glsym_func_void);
FINDSYM(glsym_glBeginPerfMonitorAMD, "glBeginPerfMonitorAMD", glsym_func_void);
FINDSYM(glsym_glEndPerfMonitorAMD, "glEndPerfMonitorAMD", glsym_func_void);
FINDSYM(glsym_glGetPerfMonitorCounterDataAMD, "glGetPerfMonitorCounterDataAMD", glsym_func_void);
if (glsym_glGetPerfMonitorGroupsAMD) _gl_ext_entries[3].supported = 1;
/* GL_EXT_discard_framebuffer */
FINDSYM(glsym_glDiscardFramebufferEXT, "glDiscardFramebuffer", glsym_func_void);
FINDSYM(glsym_glDiscardFramebufferEXT, "glDiscardFramebufferARB", glsym_func_void);
FINDSYM(glsym_glDiscardFramebufferEXT, "glDiscardFramebufferEXT", glsym_func_void);
if (glsym_glDiscardFramebufferEXT) _gl_ext_entries[4].supported = 1;
/* GL_EXT_multi_draw_arrays */
FINDSYM(glsym_glMultiDrawArraysEXT, "glMultiDrawArrays", glsym_func_void);
FINDSYM(glsym_glMultiDrawArraysEXT, "glMultiDrawArraysARB", glsym_func_void);
FINDSYM(glsym_glMultiDrawArraysEXT, "glMultiDrawArraysEXT", glsym_func_void);
FINDSYM(glsym_glMultiDrawElementsEXT, "glMultiDrawElements", glsym_func_void);
FINDSYM(glsym_glMultiDrawElementsEXT, "glMultiDrawElementsARB", glsym_func_void);
FINDSYM(glsym_glMultiDrawElementsEXT, "glMultiDrawElementsEXT", glsym_func_void);
if (glsym_glMultiDrawArraysEXT) _gl_ext_entries[5].supported = 1;
/* GL_NV_fence */
FINDSYM(glsym_glDeleteFencesNV, "glDeleteFencesNV", glsym_func_void);
FINDSYM(glsym_glGenFencesNV, "glGenFencesNV", glsym_func_void);
FINDSYM(glsym_glIsFenceNV, "glIsFenceNV", glsym_func_uchar);
FINDSYM(glsym_glTestFenceNV, "glTestFenceNV", glsym_func_uchar);
FINDSYM(glsym_glGetFenceivNV, "glGetFenceivNV", glsym_func_void);
FINDSYM(glsym_glFinishFenceNV, "glFinishFenceNV", glsym_func_void);
FINDSYM(glsym_glSetFenceNV, "glSetFenceNV", glsym_func_void);
if (glsym_glDeleteFencesNV) _gl_ext_entries[6].supported = 1;
/* GL_QCOM_driver_control */
FINDSYM(glsym_glGetDriverControlsQCOM, "glGetDriverControlsQCOM", glsym_func_void);
FINDSYM(glsym_glGetDriverControlStringQCOM, "glGetDriverControlStringQCOM", glsym_func_void);
FINDSYM(glsym_glEnableDriverControlQCOM, "glEnableDriverControlQCOM", glsym_func_void);
FINDSYM(glsym_glDisableDriverControlQCOM, "glDisableDriverControlQCOM", glsym_func_void);
if (glsym_glGetDriverControlsQCOM) _gl_ext_entries[7].supported = 1;
/* GL_QCOM_extended_get */
FINDSYM(glsym_glExtGetTexturesQCOM, "glExtGetTexturesQCOM", glsym_func_void);
FINDSYM(glsym_glExtGetBuffersQCOM, "glExtGetBuffersQCOM", glsym_func_void);
FINDSYM(glsym_glExtGetRenderbuffersQCOM, "glExtGetRenderbuffersQCOM", glsym_func_void);
FINDSYM(glsym_glExtGetFramebuffersQCOM, "glExtGetFramebuffersQCOM", glsym_func_void);
FINDSYM(glsym_glExtGetTexLevelParameterivQCOM, "glExtGetTexLevelParameterivQCOM", glsym_func_void);
FINDSYM(glsym_glExtTexObjectStateOverrideiQCOM, "glExtTexObjectStateOverrideiQCOM", glsym_func_void);
FINDSYM(glsym_glExtGetTexSubImageQCOM, "glExtGetTexSubImageQCOM", glsym_func_void);
FINDSYM(glsym_glExtGetBufferPointervQCOM, "glExtGetBufferPointervQCOM", glsym_func_void);
if (glsym_glExtGetTexturesQCOM) _gl_ext_entries[8].supported = 1;
/* GL_QCOM_extended_get2 */
FINDSYM(glsym_glExtGetShadersQCOM, "glExtGetShadersQCOM", glsym_func_void);
FINDSYM(glsym_glExtGetProgramsQCOM, "glExtGetProgramsQCOM", glsym_func_void);
FINDSYM(glsym_glExtIsProgramBinaryQCOM, "glExtIsProgramBinaryQCOM", glsym_func_uchar);
FINDSYM(glsym_glExtGetProgramBinarySourceQCOM, "glExtGetProgramBinarySourceQCOM", glsym_func_void);
if (glsym_glExtGetShadersQCOM) _gl_ext_entries[9].supported = 1;
}
static void
_extensions_init(Render_Engine *re)
{
int i;
const char *glexts, *evasglexts;
memset(_gl_ext_string, 0, 1024);
memset(_evasgl_ext_string, 0, 1024);
// GLES 2.0 Extensions
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glexts = (const char*)glGetString(GL_EXTENSIONS);
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
2011-10-18 01:13:23 -07:00
DBG("--------GLES 2.0 Extensions--------");
for (i = 0; _gl_ext_entries[i].name != NULL; i++)
{
if ( (strstr(glexts, _gl_ext_entries[i].name) != NULL) ||
(strstr(glexts, _gl_ext_entries[i].real_name) != NULL) )
{
_gl_ext_entries[i].supported = 1;
strcat(_gl_ext_string, _gl_ext_entries[i].name);
strcat(_gl_ext_string, " ");
DBG("\t%s", _gl_ext_entries[i].name);
}
}
DBG(" ");
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
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
2011-10-18 01:13:23 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// EGL Extensions
Added new Evas GL api called evas_gl_config_new/free() to ensure backward compatibility. Previously, the user simply declared a Evas_GL_Config object but this can cause problems if more config options are added. So, we have Evas allocate the config object for the user so it can handle addition in the future. Also, added some safety code around _extensions_init SVN revision: 67141
2012-01-12 05:54:06 -08:00
if (glsym_eglQueryString)
{
evasglexts = glsym_eglQueryString(re->win->egl_disp, EGL_EXTENSIONS);
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
2011-10-18 01:13:23 -07:00
#else
Added new Evas GL api called evas_gl_config_new/free() to ensure backward compatibility. Previously, the user simply declared a Evas_GL_Config object but this can cause problems if more config options are added. So, we have Evas allocate the config object for the user so it can handle addition in the future. Also, added some safety code around _extensions_init SVN revision: 67141
2012-01-12 05:54:06 -08:00
if (glsym_glXQueryExtensionsString)
{
evasglexts = glXQueryExtensionsString(re->info->info.display,
re->info->info.screen);
cedric's cache changes patch SVN revision: 34253
2008-04-11 17:32:30 -07:00
#endif
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
2011-10-18 01:13:23 -07:00
Added new Evas GL api called evas_gl_config_new/free() to ensure backward compatibility. Previously, the user simply declared a Evas_GL_Config object but this can cause problems if more config options are added. So, we have Evas allocate the config object for the user so it can handle addition in the future. Also, added some safety code around _extensions_init SVN revision: 67141
2012-01-12 05:54:06 -08:00
DBG("--------EvasGL Extensions----------");
for (i = 0; _evasgl_ext_entries[i].name != NULL; i++)
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
2011-10-18 01:13:23 -07:00
{
Added new Evas GL api called evas_gl_config_new/free() to ensure backward compatibility. Previously, the user simply declared a Evas_GL_Config object but this can cause problems if more config options are added. So, we have Evas allocate the config object for the user so it can handle addition in the future. Also, added some safety code around _extensions_init SVN revision: 67141
2012-01-12 05:54:06 -08:00
if ( (strstr(evasglexts, _evasgl_ext_entries[i].name) != NULL) ||
(strstr(evasglexts, _evasgl_ext_entries[i].real_name) != NULL) )
{
_evasgl_ext_entries[i].supported = 1;
strcat(_evasgl_ext_string, _evasgl_ext_entries[i].name);
strcat(_evasgl_ext_string, " ");
DBG("\t%s", _evasgl_ext_entries[i].name);
}
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
2011-10-18 01:13:23 -07:00
}
Added new Evas GL api called evas_gl_config_new/free() to ensure backward compatibility. Previously, the user simply declared a Evas_GL_Config object but this can cause problems if more config options are added. So, we have Evas allocate the config object for the user so it can handle addition in the future. Also, added some safety code around _extensions_init SVN revision: 67141
2012-01-12 05:54:06 -08:00
DBG(" ");
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
2011-10-18 01:13:23 -07:00
}
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
}
cedric's cache changes patch SVN revision: 34253
2008-04-11 17:32:30 -07:00
* evas: Cleanup move to eina log. Patch from Mathieu Taillefumier. SVN revision: 43200
2009-10-22 08:22:22 -07:00
int _evas_engine_GL_X11_log_dom = -1;
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
/* function tables - filled in later (func and parent func) */
static Evas_Func func, pfunc;
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
/* Function table for GL APIs */
static Evas_GL_API gl_funcs;
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
/*
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
struct xrdb_user
{
time_t last_stat;
time_t last_mtime;
XrmDatabase db;
};
static struct xrdb_user xrdb_user = {0, 0, NULL};
static Eina_Bool
xrdb_user_query(const char *name, const char *cls, char **type, XrmValue *val)
{
time_t last = xrdb_user.last_stat, now = time(NULL);
xrdb_user.last_stat = now;
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
if (last != now) // don't stat() more than once every second
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
struct stat st;
const char *home = getenv("HOME");
char tmp[PATH_MAX];
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (!home) goto failed;
snprintf(tmp, sizeof(tmp), "%s/.Xdefaults", home);
if (stat(tmp, &st) != 0) goto failed;
if (xrdb_user.last_mtime != st.st_mtime)
{
if (xrdb_user.db) XrmDestroyDatabase(xrdb_user.db);
xrdb_user.db = XrmGetFileDatabase(tmp);
if (!xrdb_user.db) goto failed;
xrdb_user.last_mtime = st.st_mtime;
}
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
}
if (!xrdb_user.db) return EINA_FALSE;
return XrmGetResource(xrdb_user.db, name, cls, type, val);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
failed:
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
if (xrdb_user.db)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
XrmDestroyDatabase(xrdb_user.db);
xrdb_user.db = NULL;
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
}
xrdb_user.last_mtime = 0;
return EINA_FALSE;
}
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
*/
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
static void *
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_info(Evas *e)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Evas_Engine_Info_GL_X11 *info;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
info = calloc(1, sizeof(Evas_Engine_Info_GL_X11));
info->magic.magic = rand();
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
info->func.best_visual_get = eng_best_visual_get;
info->func.best_colormap_get = eng_best_colormap_get;
info->func.best_depth_get = eng_best_depth_get;
big patch from Samsung SAIT (Advanced research group) for async multi-frame rendering. to turn on: 1. configure with --enable-async-render 2. export EVAS_RENDER_MODE=non-blocking presto. necessitates some api swizzling (thus the expedite. ecore etc. changes) the kind of results you get on a desktop: http://www.rasterman.com/files/evas-async-vs-none.html SVN revision: 49087
2010-05-21 00:10:45 -07:00
info->render_mode = EVAS_RENDER_MODE_BLOCKING;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
return info;
e = NULL;
}
static void
* remove 'unused parameter' warnings * i didn't touch glitz engine as it will certainly be disabled later * i'll update windows engines later SVN revision: 39274
2009-02-28 02:08:45 -08:00
eng_info_free(Evas *e __UNUSED__, void *info)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Evas_Engine_Info_GL_X11 *in;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// dont free! why bother? its not worth it
// eina_log_domain_unregister(_evas_engine_GL_X11_log_dom);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
in = (Evas_Engine_Info_GL_X11 *)info;
free(in);
}
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
static int
_re_wincheck(Render_Engine *re)
{
if (re->win->surf) return 1;
eng_window_resurf(re->win);
if (!re->win->surf)
{
better logging. * log domains in lower-case only please. let's make it a standard so we don't have to look at the code everytime to figure out the name... * logs do NOT require trailing newline (\n), it's automatic! * do NOT add newline inside log messages! * add gl_common logging. NOTE: I tried to compile all modules, but there are clear broken modules such as cairo and qtopia. Other modules like gl_sdl are broken as they were not updated to new gl_common api (resize method AFAIR). SVN revision: 53174
2010-10-07 16:46:42 -07:00
ERR("GL engine can't re-create window surface!");
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
}
return 0;
}
static void
_re_winfree(Render_Engine *re)
{
if (!re->win->surf) return;
eng_window_unsurf(re->win);
}
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
2011-10-18 01:13:23 -07:00
static Render_Engine_GL_Resource *
_create_internal_glue_resources(void *data)
{
Render_Engine *re = (Render_Engine *)data;
Render_Engine_GL_Resource *rsc;
rsc = calloc(1, sizeof(Render_Engine_GL_Resource));
if (!rsc) return NULL;
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// EGL
int context_attrs[3];
context_attrs[0] = EGL_CONTEXT_CLIENT_VERSION;
context_attrs[1] = 2;
context_attrs[2] = EGL_NONE;
// Create resource surface for EGL
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
rsc->surface = eglCreateWindowSurface(re->win->egl_disp,
re->win->egl_config,
(EGLNativeWindowType)DefaultRootWindow(re->info->info.display),
NULL);
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
2011-10-18 01:13:23 -07:00
if (!rsc->surface)
{
ERR("Creating internal resource surface failed.");
free(rsc);
return NULL;
}
// Create a resource context for EGL
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
rsc->context = eglCreateContext(re->win->egl_disp,
re->win->egl_config,
re->win->egl_context[0], // Evas' GL Context
context_attrs);
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
2011-10-18 01:13:23 -07:00
if (!rsc->context)
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{
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
2011-10-18 01:13:23 -07:00
ERR("Internal Resource Context Creations Failed.");
free(rsc);
return NULL;
}
// Add to the resource resource list for cleanup
LKL(resource_lock);
resource_list = eina_list_prepend(resource_list, rsc);
LKU(resource_lock);
// Set the resource in TLS
if (eina_tls_set(resource_key, (void*)rsc) == EINA_FALSE)
{
ERR("Failed setting TLS Resource");
free(rsc);
return NULL;
}
#else
// GLX
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
rsc->context = glXCreateContext(re->info->info.display,
re->win->visualinfo,
re->win->context, // Evas' GL Context
1);
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
2011-10-18 01:13:23 -07:00
if (!rsc->context)
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
{
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
2011-10-18 01:13:23 -07:00
ERR("Internal Resource Context Creations Failed.");
free(rsc);
return NULL;
}
// Add to the resource resource list for cleanup
LKL(resource_lock);
resource_list = eina_list_prepend(resource_list, rsc);
LKU(resource_lock);
// Set the resource in TLS
if (eina_tls_set(resource_key, (void*)rsc) == EINA_FALSE)
{
ERR("Failed setting TLS Resource");
free(rsc);
return NULL;
}
#endif
return rsc;
}
static int
_destroy_internal_glue_resources(void *data)
{
Render_Engine *re = (Render_Engine *)data;
Eina_List *l;
Render_Engine_GL_Resource *rsc;
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// EGL
// Delete the Resources
LKL(resource_lock);
EINA_LIST_FOREACH(resource_list, l, rsc)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (rsc->surface) eglDestroySurface(re->win->egl_disp, rsc->surface);
if (rsc->context) eglDestroyContext(re->win->egl_disp, rsc->context);
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
2011-10-18 01:13:23 -07:00
free(rsc);
}
eina_list_free(resource_list);
LKU(resource_lock);
// Destroy TLS
eina_tls_free(resource_key);
#else
// GLX
// Delete the Resources
LKL(resource_lock);
EINA_LIST_FOREACH(resource_list, l, rsc)
{
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
if (rsc)
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
2011-10-18 01:13:23 -07:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glXDestroyContext(re->info->info.display, rsc->context);
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
2011-10-18 01:13:23 -07:00
free(rsc);
}
}
eina_list_free(resource_list);
LKU(resource_lock);
// Destroy TLS
eina_tls_free(resource_key);
#endif
return 1;
}
API break (well, kind of...) * evas_engine_info_set() returns now an int, to inform if an error occured or not when setting the info of the engine. * in the Evas_Func structure, the setup() method returns an int * all the engines are updated I'll fix ecore_evas and ewl later (the compilation is still fine). Gustavo: should I add EINA_WARN_UNUSED_RESULT at the end of the evas_engine_info_set() function ? SVN revision: 39670
2009-03-24 02:05:32 -07:00
static int
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_setup(Evas *e, void *in)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
Evas_Engine_Info_GL_X11 *info;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
info = (Evas_Engine_Info_GL_X11 *)in;
if (!e->engine.data.output)
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
{
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#else
fix variable SVN revision: 45427
2010-01-21 21:55:46 -08:00
int eb, evb;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (!glXQueryExtension(info->info.display, &eb, &evb)) return 0;
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
#endif
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
re = calloc(1, sizeof(Render_Engine));
if (!re) return 0;
add pre/post swap callbacks. need them! :( SVN revision: 45514
2010-01-24 03:01:20 -08:00
re->info = info;
re->evas = e;
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
e->engine.data.output = re;
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
re->w = e->output.w;
re->h = e->output.h;
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
re->win = eng_window_new(re->info->info.display,
re->info->info.drawable,
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
re->info->info.screen,
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
re->info->info.visual,
re->info->info.colormap,
re->info->info.depth,
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
re->w,
re->h,
re->info->indirect,
re->info->info.destination_alpha,
re->info->info.rotation);
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
if (!re->win)
{
free(re);
e->engine.data.output = NULL;
return 0;
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
2011-10-18 01:13:23 -07:00
}
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
gl_wins++;
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
/*
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
{
int status;
char *type = NULL;
XrmValue val;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
re->xr.dpi = 75000; // dpy * 1000
Load Xft.dpi from ~/.Xdefaults as well. Do this for consistency with other applications, some people just set .Xdefaults but do not have xrdb to load it to screen. This works with most of the systems, like Gtk and Qt, but not in Evas, so we get different font sizes as they calculate based on DPI. HOWEVER, and this may be a big thing, so RASTERMAN take a look, this might impose a performance hit on window creation... remember that every E17 popup/tooltip will hit this process of reading the file (if exists) and then query X server (round trip). I'd rather make this a global resource, loaded just once for all created windows, we can store the mtime to know when it changed and invalidate the pointer... but as Raster did not keep the XrmGetDatabase() result as global, I'm not doing it here either. SVN revision: 48403
2010-04-28 13:26:04 -07:00
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
2011-10-18 01:13:23 -07:00
status = xrdb_user_query("Xft.dpi", "Xft.Dpi", &type, &val);
if ((!status) || (!type))
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
{
if (!re->xrdb) re->xrdb = XrmGetDatabase(re->info->info.display);
if (re->xrdb)
status = XrmGetResource(re->xrdb,
"Xft.dpi", "Xft.Dpi", &type, &val);
}
Load Xft.dpi from ~/.Xdefaults as well. Do this for consistency with other applications, some people just set .Xdefaults but do not have xrdb to load it to screen. This works with most of the systems, like Gtk and Qt, but not in Evas, so we get different font sizes as they calculate based on DPI. HOWEVER, and this may be a big thing, so RASTERMAN take a look, this might impose a performance hit on window creation... remember that every E17 popup/tooltip will hit this process of reading the file (if exists) and then query X server (round trip). I'd rather make this a global resource, loaded just once for all created windows, we can store the mtime to know when it changed and invalidate the pointer... but as Raster did not keep the XrmGetDatabase() result as global, I'm not doing it here either. SVN revision: 48403
2010-04-28 13:26:04 -07:00
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
if ((status) && (type))
{
if (!strcmp(type, "String"))
{
const char *str, *dp;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
str = val.addr;
dp = strchr(str, '.');
if (!dp) dp = strchr(str, ',');
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
if (dp)
{
int subdpi, len, i;
char *buf;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
buf = alloca(dp - str + 1);
strncpy(buf, str, dp - str);
buf[dp - str] = 0;
len = strlen(dp + 1);
subdpi = atoi(dp + 1);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
if (len < 3)
{
for (i = len; i < 3; i++) subdpi *= 10;
}
else if (len > 3)
{
for (i = len; i > 3; i--) subdpi /= 10;
}
re->xr.dpi = atoi(buf) * 1000;
}
else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
re->xr.dpi = atoi(str) * 1000;
more complete gl-texture-pixmap handling, but still is broken on fglrx. hmmm. SVN revision: 45750
2010-01-30 18:50:01 -08:00
evas_common_font_dpi_set(re->xr.dpi / 1000);
allow x11 engines to get x resource that sets dpi. SVN revision: 44965
2010-01-07 23:10:53 -08:00
}
}
}
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
*/
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
if (!initted)
{
evas_common_cpu_init();
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
evas_common_blend_init();
evas_common_image_init();
evas_common_convert_init();
evas_common_scale_init();
evas_common_rectangle_init();
evas_common_polygon_init();
evas_common_line_init();
evas_common_font_init();
evas_common_draw_init();
evas_common_tilebuf_init();
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
2011-10-18 01:13:23 -07:00
// Initialize TLS
if (eina_tls_new(&resource_key) == EINA_FALSE)
ERR("Error creating tls key");
DBG("TLS KEY create... %d", resource_key);
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
initted = 1;
}
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
}
umm... handle rgba dest properly... SVN revision: 21090
2006-03-08 00:02:34 -08:00
else
{
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
re = e->engine.data.output;
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
if (_re_wincheck(re))
more debugging SVN revision: 45551
2010-01-25 06:02:14 -08:00
{
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
if ((re->info->info.display != re->win->disp) ||
(re->info->info.drawable != re->win->win) ||
(re->info->info.screen != re->win->screen) ||
(re->info->info.visual != re->win->visual) ||
(re->info->info.colormap != re->win->colormap) ||
(re->info->info.depth != re->win->depth) ||
(re->info->info.destination_alpha != re->win->alpha) ||
(re->info->info.rotation != re->win->rot))
try this one SVN revision: 50589
2010-07-28 01:11:30 -07:00
{
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
int inc = 0;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
if (re->win)
{
re->win->gl_context->references++;
eng_window_free(re->win);
inc = 1;
gl_wins--;
}
re->w = e->output.w;
re->h = e->output.h;
re->win = eng_window_new(re->info->info.display,
re->info->info.drawable,
re->info->info.screen,
re->info->info.visual,
re->info->info.colormap,
re->info->info.depth,
re->w,
re->h,
re->info->indirect,
re->info->info.destination_alpha,
re->info->info.rotation);
and now REALLY fix that viewport bug... SVN revision: 58386
2011-04-06 03:11:01 -07:00
eng_window_use(re->win);
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
if (re->win) gl_wins++;
if ((re->win) && (inc))
re->win->gl_context->references--;
}
else if ((re->win->w != e->output.w) ||
(re->win->h != e->output.h))
{
re->w = e->output.w;
re->h = e->output.h;
re->win->w = e->output.w;
re->win->h = e->output.h;
eng_window_use(re->win);
evas_gl_common_context_resize(re->win->gl_context, re->win->w, re->win->h, re->win->rot);
try this one SVN revision: 50589
2010-07-28 01:11:30 -07:00
}
more debugging SVN revision: 45551
2010-01-25 06:02:14 -08:00
}
umm... handle rgba dest properly... SVN revision: 21090
2006-03-08 00:02:34 -08:00
}
if shader compile fails - peroclate error back up to engine info_set so we know gl engine is useless. SVN revision: 48956
2010-05-17 20:49:59 -07:00
if (!re->win)
{
free(re);
return 0;
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if shader compile fails - peroclate error back up to engine info_set so we know gl engine is useless. SVN revision: 48956
2010-05-17 20:49:59 -07:00
if (!e->engine.data.output)
{
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
if (re->win)
{
eng_window_free(re->win);
gl_wins--;
}
if shader compile fails - peroclate error back up to engine info_set so we know gl engine is useless. SVN revision: 48956
2010-05-17 20:49:59 -07:00
free(re);
return 0;
}
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
re->tb = evas_common_tilebuf_new(re->win->w, re->win->h);
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
if (!re->tb)
{
if (re->win)
{
eng_window_free(re->win);
gl_wins--;
}
free(re);
return 0;
}
evas_common_tilebuf_set_tile_size(re->tb, TILESIZE, TILESIZE);
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
if (!e->engine.data.context)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
e->engine.data.context =
e->engine.func->context_new(e->engine.data.output);
more work putting shared bits in shared. but context seems to be a big problem. :( SVN revision: 43048
2009-10-13 02:40:39 -07:00
eng_window_use(re->win);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
only set swap interval if it changes for egl - and dont waitgl if swap native is available. SVN revision: 53849
2010-10-25 00:22:43 -07:00
re->vsync = 0;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
_sym_init();
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
2011-10-18 01:13:23 -07:00
_extensions_init(re);
// This is used in extensions. Not pretty but can't get display otherwise.
current_engine = re;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
API break (well, kind of...) * evas_engine_info_set() returns now an int, to inform if an error occured or not when setting the info of the engine. * in the Evas_Func structure, the setup() method returns an int * all the engines are updated I'll fix ecore_evas and ewl later (the compilation is still fine). Gustavo: should I add EINA_WARN_UNUSED_RESULT at the end of the evas_engine_info_set() function ? SVN revision: 39670
2009-03-24 02:05:32 -07:00
return 1;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_output_free(void *data)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if shader compile fails - peroclate error back up to engine info_set so we know gl engine is useless. SVN revision: 48956
2010-05-17 20:49:59 -07:00
if (re)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// NOTE: XrmGetDatabase() result is shared per connection, do not free it.
// if (re->xrdb) XrmDestroyDatabase(re->xrdb);
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
#if 0
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// Destroy the resource surface
// Only required for EGL case
if (re->surface)
eglDestroySurface(re->win->egl_disp, re->surface);
#endif
// Destroy the resource context
_destroy_internal_context(re, context);
#endif
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
if (re->win)
{
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
2011-10-18 01:13:23 -07:00
if ((initted == 1) && (gl_wins == 1))
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
_destroy_internal_glue_resources(re);
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
eng_window_free(re->win);
gl_wins--;
}
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
evas_common_tilebuf_free(re->tb);
if shader compile fails - peroclate error back up to engine info_set so we know gl engine is useless. SVN revision: 48956
2010-05-17 20:49:59 -07:00
free(re);
}
handle gl init fialure correctly and dont mess up font init. SVN revision: 48959
2010-05-17 21:22:33 -07:00
if ((initted == 1) && (gl_wins == 0))
{
evas_common_image_shutdown();
evas_common_font_shutdown();
initted = 0;
}
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_output_resize(void *data, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
re->win->w = w;
re->win->h = h;
more work putting shared bits in shared. but context seems to be a big problem. :( SVN revision: 43048
2009-10-13 02:40:39 -07:00
eng_window_use(re->win);
gl engine now does rotates (0, 90, 180, 270), like software engines SVN revision: 48704
2010-05-08 22:15:20 -07:00
evas_gl_common_context_resize(re->win->gl_context, w, h, re->win->rot);
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
evas_common_tilebuf_free(re->tb);
re->tb = evas_common_tilebuf_new(w, h);
if (re->tb)
evas_common_tilebuf_set_tile_size(re->tb, TILESIZE, TILESIZE);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
eng_output_tile_size_set(void *data, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
Render_Engine *re;
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
re = (Render_Engine *)data;
evas_common_tilebuf_set_tile_size(re->tb, w, h);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_output_redraws_rect_add(void *data, int x, int y, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
eng_window_use(re->win);
gl engine now does rotates (0, 90, 180, 270), like software engines SVN revision: 48704
2010-05-08 22:15:20 -07:00
evas_gl_common_context_resize(re->win->gl_context, re->win->w, re->win->h, re->win->rot);
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
evas_common_tilebuf_add_redraw(re->tb, x, y, w, h);
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
work on adding copy back -> front partial swaps back in... tho it does nothing atm.. odd! disabled tho. SVN revision: 46077
2010-02-11 06:41:44 -08:00
RECTS_CLIP_TO_RECT(x, y, w, h, 0, 0, re->win->w, re->win->h);
if ((w <= 0) || (h <= 0)) return;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
if (!re->win->draw.redraw)
{
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
#if 1
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
re->win->draw.x1 = x;
re->win->draw.y1 = y;
re->win->draw.x2 = x + w - 1;
re->win->draw.y2 = y + h - 1;
force fullscreen edraws for gl - this holw buffer swap thing just doesnt work well otherwise... - and copying from back to front buffer is really a no-go :( SVN revision: 10538
2004-06-18 08:56:30 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
re->win->draw.x1 = 0;
re->win->draw.y1 = 0;
re->win->draw.x2 = re->win->w - 1;
re->win->draw.y2 = re->win->h - 1;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
#endif
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
}
else
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (x < re->win->draw.x1) re->win->draw.x1 = x;
if (y < re->win->draw.y1) re->win->draw.y1 = y;
if ((x + w - 1) > re->win->draw.x2) re->win->draw.x2 = x + w - 1;
if ((y + h - 1) > re->win->draw.y2) re->win->draw.y2 = y + h - 1;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
}
re->win->draw.redraw = 1;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
Evas (gl engine): Remove incorrect __UNUSED__ on paramaters that are actually used. SVN revision: 65928
2011-12-05 16:44:25 -08:00
eng_output_redraws_rect_del(void *data, int x, int y, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
Render_Engine *re;
re = (Render_Engine *)data;
evas_common_tilebuf_del_redraw(re->tb, x, y, w, h);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_output_redraws_clear(void *data)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
evas_common_tilebuf_clear(re->tb);
/* re->win->draw.redraw = 0;*/
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// INF("GL: finish update cycle!");
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
just look at the comments to know what this is about. SVN revision: 28545
2007-03-03 08:05:15 -08:00
/* vsync games - not for now though */
put in little vsync option and section. not turned on by anything yet. SVN revision: 45708
2010-01-29 09:14:50 -08:00
#define VSYNC_TO_SCREEN 1
just look at the comments to know what this is about. SVN revision: 28545
2007-03-03 08:05:15 -08:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
static void *
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_output_redraws_next_update_get(void *data, int *x, int *y, int *w, int *h, int *cx, int *cy, int *cw, int *ch)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
Tilebuf_Rect *rects;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
/* get the upate rect surface - return engine data as dummy */
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
rects = evas_common_tilebuf_get_render_rects(re->tb);
if (rects)
{
debug for future. for now found the problem. SVN revision: 64248
2011-10-21 02:59:13 -07:00
/*
Tilebuf_Rect *r;
printf("REAAAAACCTS\n");
EINA_INLIST_FOREACH(EINA_INLIST_GET(rects), r)
{
printf(" %i %i %ix%i\n", r->x, r->y, r->w, r->h);
}
*/
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
evas_common_tilebuf_free_render_rects(rects);
evas_common_tilebuf_clear(re->tb);
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// dont need to for egl - eng_window_use() can check for other ctxt's
#else
eng_window_use(NULL);
#endif
eng_window_use(re->win);
if (!_re_wincheck(re)) return NULL;
evas_gl_common_context_flush(re->win->gl_context);
evas_gl_common_context_newframe(re->win->gl_context);
if (x) *x = 0;
if (y) *y = 0;
if (w) *w = re->win->w;
if (h) *h = re->win->h;
if (cx) *cx = 0;
if (cy) *cy = 0;
if (cw) *cw = re->win->w;
if (ch) *ch = re->win->h;
return re->win->gl_context->def_surface;
}
return NULL;
/*
work on adding copy back -> front partial swaps back in... tho it does nothing atm.. odd! disabled tho. SVN revision: 46077
2010-02-11 06:41:44 -08:00
if (!re->win->draw.redraw) return NULL;
egl actually doesnt need a full reset - we CAN get the current context and draw/read surfaces. SVN revision: 55977
2011-01-07 02:16:17 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// dont need to for egl - eng_window_use() can check for other ctxt's
#else
make sure we ensure out gl context is current at each frame start SVN revision: 55131
2010-12-02 00:01:19 -08:00
eng_window_use(NULL);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#endif
make sure we ensure out gl context is current at each frame start SVN revision: 55131
2010-12-02 00:01:19 -08:00
eng_window_use(re->win);
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
if (!_re_wincheck(re)) return NULL;
be paranoid about gl context - reset it to "0" every frame. SVN revision: 49065
2010-05-20 08:24:28 -07:00
evas_gl_common_context_flush(re->win->gl_context);
evas_gl_common_context_newframe(re->win->gl_context);
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
if (x) *x = re->win->draw.x1;
if (y) *y = re->win->draw.y1;
if (w) *w = re->win->draw.x2 - re->win->draw.x1 + 1;
if (h) *h = re->win->draw.y2 - re->win->draw.y1 + 1;
if (cx) *cx = re->win->draw.x1;
if (cy) *cy = re->win->draw.y1;
if (cw) *cw = re->win->draw.x2 - re->win->draw.x1 + 1;
if (ch) *ch = re->win->draw.y2 - re->win->draw.y1 + 1;
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
return re->win->gl_context->def_surface;
have evas engine also to update rect math so we can exclude useless updates when obscured objects change SVN revision: 64246
2011-10-21 01:58:00 -07:00
*/
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
//#define FRAMECOUNT 1
Evas (gl_x11 engine): Fix compiler warning about get_time function. SVN revision: 67058
2012-01-11 01:48:47 -08:00
#ifdef FRAMECOUNT
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
static double
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
get_time(void)
{
Evas (gl_x11 engine): Fix compiler warning about get_time function. SVN revision: 67058
2012-01-11 01:48:47 -08:00
struct timeval timev;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
gettimeofday(&timev, NULL);
return (double)timev.tv_sec + (((double)timev.tv_usec) / 1000000);
}
Evas (gl_x11 engine): Fix compiler warning about get_time function. SVN revision: 67058
2012-01-11 01:48:47 -08:00
#endif
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
only set swap interval if it changes for egl - and dont waitgl if swap native is available. SVN revision: 53849
2010-10-25 00:22:43 -07:00
static int safe_native = -1;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
static void
* remove 'unused parameter' warnings * i didn't touch glitz engine as it will certainly be disabled later * i'll update windows engines later SVN revision: 39274
2009-02-28 02:08:45 -08:00
eng_output_redraws_next_update_push(void *data, void *surface __UNUSED__, int x __UNUSED__, int y __UNUSED__, int w __UNUSED__, int h __UNUSED__)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
#ifdef FRAMECOUNT
static double pt = 0.0;
double ta, tb;
#endif
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
/* put back update surface.. in this case just unflag redraw */
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
if (!_re_wincheck(re)) return;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
re->win->draw.redraw = 0;
fix nul update on swap SVN revision: 28556
2007-03-04 09:06:13 -08:00
re->win->draw.drew = 1;
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
evas_gl_common_context_flush(re->win->gl_context);
allow evas gl engine skipping wait native if known to be safe. SVN revision: 53760
2010-10-22 01:17:37 -07:00
if (safe_native == -1)
{
const char *s = getenv("EVAS_GL_SAFE_NATIVE");
safe_native = 0;
if (s) safe_native = atoi(s);
put in special known "save native" case to avoid needing the env var. SVN revision: 53844
2010-10-24 18:57:48 -07:00
else
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
s = (const char *)glGetString(GL_RENDERER);
put in special known "save native" case to avoid needing the env var. SVN revision: 53844
2010-10-24 18:57:48 -07:00
if (s)
{
evas/evas_engine - patched by Seung-Soo Woo. Dear all, There is a below issue. Problem : Evas gl engine call eglWaitNative() and eglWaitGL() before/after eglSwapBuffers(). The sync APIs are not call only in case of SGX_DDK. Resolution : It is necessary to check MALI string too. So, I fixed it. Please find enclosed file. Thanks. SVN revision: 61226
2011-07-10 23:29:20 -07:00
if (strstr(s, "PowerVR SGX 540") ||
evas: Fixed indentations with arbitrary files. SVN revision: 62370
2011-08-11 20:50:57 -07:00
strstr(s, "Mali-400 MP"))
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
safe_native = 1;
put in special known "save native" case to avoid needing the env var. SVN revision: 53844
2010-10-24 18:57:48 -07:00
}
}
allow evas gl engine skipping wait native if known to be safe. SVN revision: 53760
2010-10-22 01:17:37 -07:00
}
fix! broek egl compositing. fixed now. SVN revision: 45792
2010-02-01 21:30:19 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
reduce binds when things get clipped and split. SVN revision: 45928
2010-02-06 00:38:26 -08:00
// this is needed to make sure all previous rendering is flushed to
// buffers/surfaces
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
#ifdef FRAMECOUNT
double t0 = get_time();
ta = t0 - pt;
pt = t0;
#endif
allow evas gl engine skipping wait native if known to be safe. SVN revision: 53760
2010-10-22 01:17:37 -07:00
// previous rendering should be done and swapped
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (!safe_native) eglWaitNative(EGL_CORE_NATIVE_ENGINE);
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
#ifdef FRAMECOUNT
double t1 = get_time();
tb = t1 - t0;
printf("... %1.5f -> %1.5f | ", ta, tb);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// if (eglGetError() != EGL_SUCCESS)
// {
// printf("Error: eglWaitNative(EGL_CORE_NATIVE_ENGINE) fail.\n");
// }
fix! broek egl compositing. fixed now. SVN revision: 45792
2010-02-01 21:30:19 -08:00
#else
allow evas gl engine skipping wait native if known to be safe. SVN revision: 53760
2010-10-22 01:17:37 -07:00
// previous rendering should be done and swapped
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (!safe_native) glXWaitX();
fix! broek egl compositing. fixed now. SVN revision: 45792
2010-02-01 21:30:19 -08:00
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
//x// printf("frame -> push\n");
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_output_flush(void *data)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
if (!_re_wincheck(re)) return;
fix nul update on swap SVN revision: 28556
2007-03-04 09:06:13 -08:00
if (!re->win->draw.drew) return;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
//x// printf("frame -> flush\n");
fix nul update on swap SVN revision: 28556
2007-03-04 09:06:13 -08:00
re->win->draw.drew = 0;
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
add pre/post swap callbacks. need them! :( SVN revision: 45514
2010-01-24 03:01:20 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
#ifdef FRAMECOUNT
double t0 = get_time();
dont sync if vsync not set...? (good?) SVN revision: 50735
2010-08-01 23:44:23 -07:00
#endif
only set swap interval if it changes for egl - and dont waitgl if swap native is available. SVN revision: 53849
2010-10-25 00:22:43 -07:00
if (!re->vsync)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (re->info->vsync) eglSwapInterval(re->win->egl_disp, 1);
else eglSwapInterval(re->win->egl_disp, 0);
only set swap interval if it changes for egl - and dont waitgl if swap native is available. SVN revision: 53849
2010-10-25 00:22:43 -07:00
re->vsync = 1;
}
Fix: egl mode in engine forgot to call pre/post swap callback. thanks guanglim! SVN revision: 59322
2011-05-11 02:14:59 -07:00
if (re->info->callback.pre_swap)
{
re->info->callback.pre_swap(re->info->callback.data, re->evas);
}
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
eglSwapBuffers(re->win->egl_disp, re->win->egl_surface[0]);
if (!safe_native) eglWaitGL();
Fix: egl mode in engine forgot to call pre/post swap callback. thanks guanglim! SVN revision: 59322
2011-05-11 02:14:59 -07:00
if (re->info->callback.post_swap)
{
re->info->callback.post_swap(re->info->callback.data, re->evas);
}
some debugging i get to turn on sometimes... off now. SVN revision: 47618
2010-03-31 02:25:21 -07:00
#ifdef FRAMECOUNT
double t1 = get_time();
printf("%1.5f\n", t1 - t0);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// if (eglGetError() != EGL_SUCCESS)
// {
// printf("Error: eglSwapBuffers() fail.\n");
// }
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
#else
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#ifdef VSYNC_TO_SCREEN
work on adding copy back -> front partial swaps back in... tho it does nothing atm.. odd! disabled tho. SVN revision: 46077
2010-02-11 06:41:44 -08:00
if ((re->info->vsync)/* || (1)*/)
put in little vsync option and section. not turned on by anything yet. SVN revision: 45708
2010-01-29 09:14:50 -08:00
{
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
2011-10-18 01:13:23 -07:00
if (glsym_glXSwapIntervalEXT)
2 different sync apis with differetn ext's. fix. SVN revision: 57569
2011-03-08 03:20:49 -08:00
{
if (!re->vsync)
{
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
2011-10-18 01:13:23 -07:00
if (re->info->vsync) glsym_glXSwapIntervalEXT(re->win->disp, re->win->win, 1);
else glsym_glXSwapIntervalEXT(re->win->disp, re->win->win, 0);
2 different sync apis with differetn ext's. fix. SVN revision: 57569
2011-03-08 03:20:49 -08:00
re->vsync = 1;
}
}
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
2011-10-18 01:13:23 -07:00
if (glsym_glXSwapIntervalSGI)
put in little vsync option and section. not turned on by anything yet. SVN revision: 45708
2010-01-29 09:14:50 -08:00
{
missing support for swapinterval api in glx. SVN revision: 55754
2010-12-26 02:15:28 -08:00
if (!re->vsync)
{
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
2011-10-18 01:13:23 -07:00
if (re->info->vsync) glsym_glXSwapIntervalSGI(1);
else glsym_glXSwapIntervalSGI(0);
missing support for swapinterval api in glx. SVN revision: 55754
2010-12-26 02:15:28 -08:00
re->vsync = 1;
}
}
else
{
if ((glsym_glXGetVideoSync) && (glsym_glXWaitVideoSync))
{
unsigned int rc;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
missing support for swapinterval api in glx. SVN revision: 55754
2010-12-26 02:15:28 -08:00
glsym_glXGetVideoSync(&rc);
glsym_glXWaitVideoSync(1, 0, &rc);
}
put in little vsync option and section. not turned on by anything yet. SVN revision: 45708
2010-01-29 09:14:50 -08:00
}
}
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
# endif
add pre/post swap callbacks. need them! :( SVN revision: 45514
2010-01-24 03:01:20 -08:00
if (re->info->callback.pre_swap)
{
re->info->callback.pre_swap(re->info->callback.data, re->evas);
}
oops dont enable copy path! SVN revision: 66727
2012-01-01 19:32:57 -08:00
#if 1
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
if (1)
#else
if ((re->win->draw.x1 == 0) && (re->win->draw.y1 == 0) && (re->win->draw.x2 == (re->win->w - 1)) && (re->win->draw.y2 == (re->win->h - 1)))
#endif
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
{
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
// double t, t2 = 0.0;
// t = get_time();
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glXSwapBuffers(re->win->disp, re->win->win);
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
// t = get_time() - t;
// if (!safe_native)
// {
// t2 = get_time();
// glXWaitGL();
// t2 = get_time() - t2;
// }
// printf("swap: %3.5f (%3.5fms), x wait gl: %3.5f (%3.5fms)\n",
// t, t * 1000.0, t2, t2 * 1000.0);
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
}
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
else
{
// FIXME: this doesn't work.. why oh why?
int sx, sy, sw, sh;
sx = re->win->draw.x1;
sy = re->win->draw.y1;
sw = (re->win->draw.x2 - re->win->draw.x1) + 1;
sh = (re->win->draw.y2 - re->win->draw.y1) + 1;
sy = re->win->h - sy - sh;
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
make some more notes for partial swap (copy gabk to front) but still doesnt work.. just sits there and does nothing. wtf. SVN revision: 66726
2012-01-01 19:30:23 -08:00
glBitmap(0, 0, 0, 0, sx, re->win->h - sy, NULL);
glEnable(GL_SCISSOR_TEST);
glScissor(sx, sy, sw, sh);
found nvidia eat-cpu-bug. glXWaitGL() spins using all cpu it can find, though nvidia fixed the spinning on glXSwapBuffers() long ago, they didn't fix this one. SVN revision: 66710
2011-12-31 22:47:16 -08:00
glDrawBuffer(GL_FRONT);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glCopyPixels(sx, sy, sw, sh, GL_COLOR);
glDrawBuffer(GL_BACK);
make some more notes for partial swap (copy gabk to front) but still doesnt work.. just sits there and does nothing. wtf. SVN revision: 66726
2012-01-01 19:30:23 -08:00
glDisable(GL_SCISSOR_TEST);
glBitmap(0, 0, 0, 0, 0, 0, NULL);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glFlush();
}
add pre/post swap callbacks. need them! :( SVN revision: 45514
2010-01-24 03:01:20 -08:00
if (re->info->callback.post_swap)
{
re->info->callback.post_swap(re->info->callback.data, re->evas);
}
begin work on argb window support for gl - glx/gl doesnt work. i think egl/gles will tho. SVN revision: 46677
2010-02-28 20:44:23 -08:00
#endif
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
add an engine idle flush SVN revision: 30355
2007-06-16 19:56:59 -07:00
static void
eng_output_idle_flush(void *data)
{
add ability to dump engine coontents (if engine supports it). this means unload images it has loaded from disk, unload fonts, and more. dump dump dump! SVN revision: 47947
2010-04-12 01:23:53 -07:00
Render_Engine *re;
re = (Render_Engine *)data;
}
static void
eng_output_dump(void *data)
{
Render_Engine *re;
re = (Render_Engine *)data;
evas_common_image_image_all_unload();
evas_common_font_font_all_unload();
evas_gl_common_image_all_unload(re->win->gl_context);
be able to free and alloc gl surface when asked to dump SVN revision: 51654
2010-08-26 02:40:48 -07:00
_re_winfree(re);
add an engine idle flush SVN revision: 30355
2007-06-16 19:56:59 -07:00
}
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
static void
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_context_cutout_add(void *data __UNUSED__, void *context, int x, int y, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
//
// re = (Render_Engine *)data;
// re->win->gl_context->dc = context;
1. make software font draw code actually use cutouts. 2. make gl engine able to use cutouts - in some cases its faster, some slower. it's a mixed bag. not sure what to make of it. it's #defined to be disabled atm. SVN revision: 39114
2009-02-20 19:13:49 -08:00
evas_common_draw_context_add_cutout(context, x, y, w, h);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_context_cutout_clear(void *data __UNUSED__, void *context)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
//
// re = (Render_Engine *)data;
// re->win->gl_context->dc = context;
1. make software font draw code actually use cutouts. 2. make gl engine able to use cutouts - in some cases its faster, some slower. it's a mixed bag. not sure what to make of it. it's #defined to be disabled atm. SVN revision: 39114
2009-02-20 19:13:49 -08:00
evas_common_draw_context_clear_cutouts(context);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
eng_rectangle_draw(void *data, void *context, void *surface, int x, int y, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
same as previous commit. SVN revision: 26236
2006-09-30 03:18:37 -07:00
re->win->gl_context->dc = context;
evas_gl_common_rect_draw(re->win->gl_context, x, y, w, h);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
eng_line_draw(void *data, void *context, void *surface, int x1, int y1, int x2, int y2)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
eng_window_use(re->win);
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
same as previous commit. SVN revision: 26236
2006-09-30 03:18:37 -07:00
re->win->gl_context->dc = context;
1. line support in gl engine - as if anyone uses lines 2. fix clipping for gl maps - was setting them when it shouldnt. SVN revision: 44782
2009-12-30 03:35:40 -08:00
evas_gl_common_line_draw(re->win->gl_context, x1, y1, x2, y2);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
* remove 'unused parameter' warnings * i didn't touch glitz engine as it will certainly be disabled later * i'll update windows engines later SVN revision: 39274
2009-02-28 02:08:45 -08:00
eng_polygon_point_add(void *data, void *context __UNUSED__, void *polygon, int x, int y)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
gl -> polygons now work. slow - but does it matter? SVN revision: 44724
2009-12-26 16:40:25 -08:00
return evas_gl_common_poly_point_add(polygon, x, y);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
* remove 'unused parameter' warnings * i didn't touch glitz engine as it will certainly be disabled later * i'll update windows engines later SVN revision: 39274
2009-02-28 02:08:45 -08:00
eng_polygon_points_clear(void *data, void *context __UNUSED__, void *polygon)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
gl -> polygons now work. slow - but does it matter? SVN revision: 44724
2009-12-26 16:40:25 -08:00
return evas_gl_common_poly_points_clear(polygon);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
* evas: Make evas_object_move on Evas_Object_Polygon work. TODO: Make evas_object_resize work also. SVN revision: 47291
2010-03-16 06:23:37 -07:00
eng_polygon_draw(void *data, void *context, void *surface __UNUSED__, void *polygon, int x, int y)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
eng_window_use(re->win);
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
same as previous commit. SVN revision: 26236
2006-09-30 03:18:37 -07:00
re->win->gl_context->dc = context;
* evas: Make evas_object_move on Evas_Object_Polygon work. TODO: Make evas_object_resize work also. SVN revision: 47291
2010-03-16 06:23:37 -07:00
evas_gl_common_poly_draw(re->win->gl_context, polygon, x, y);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
static int
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_alpha_get(void *data __UNUSED__, void *image)
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
Evas_GL_Image *im;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// re = (Render_Engine *)data;
fix segv added in SVN revision: 27499
2006-12-17 08:46:30 -08:00
if (!image) return 1;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
im = image;
some more cleanups - issed protecting 1 or 2 calls. gl still doesnt work tho :) not on fglrx. SVN revision: 45388
2010-01-21 04:43:53 -08:00
return im->alpha;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
}
static int
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_colorspace_get(void *data __UNUSED__, void *image)
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
Evas_GL_Image *im;
remove trailing spaces SVN revision: 39117
2009-02-21 00:19:58 -08:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// re = (Render_Engine *)data;
fix segv added in SVN revision: 27499
2006-12-17 08:46:30 -08:00
if (!image) return EVAS_COLORSPACE_ARGB8888;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
im = image;
return im->cs.space;
}
Masking: Push a bit more arbitrary clipping This seems to have got lost in my big messup before. This pushes enough of mask/arbitrary clip to be somewhat useful. I need to push a little more soon for it to be 100% happy, but this is useful level. SVN revision: 58373
2011-04-05 22:38:38 -07:00
static void
eng_image_mask_create(void *data __UNUSED__, void *image)
{
Evas_GL_Image *im;
if (!image) return;
im = image;
if (!im->im->image.data)
evas_cache_image_load_data(&im->im->cache_entry);
if (!im->tex)
im->tex = evas_gl_common_texture_new(im->gc, im->im);
}
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
static void *
eng_image_alpha_set(void *data, void *image, int has_alpha)
{
Render_Engine *re;
Evas_GL_Image *im;
re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image) return NULL;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
im = image;
and make dynamic hint actually work when we have zero-copy texture support. fully ok now for argb8888. SVN revision: 51380
2010-08-18 22:18:17 -07:00
if (im->alpha == has_alpha) return image;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (im->native.data)
{
im->alpha = has_alpha;
return image;
}
some more cleanups - issed protecting 1 or 2 calls. gl still doesnt work tho :) not on fglrx. SVN revision: 45388
2010-01-21 04:43:53 -08:00
eng_window_use(re->win);
and make dynamic hint actually work when we have zero-copy texture support. fully ok now for argb8888. SVN revision: 51380
2010-08-18 22:18:17 -07:00
if ((im->tex) && (im->tex->pt->dyn.img))
{
im->alpha = has_alpha;
im->tex->alpha = im->alpha;
return image;
}
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
/* FIXME: can move to gl_common */
if (im->cs.space != EVAS_COLORSPACE_ARGB8888) return im;
* Make RGBA_IMAGE_HAS_ALPHA and RGBA_IMAGE_ALPHA_SPARSE part of Image_Entry flag structure. This fix a bug with 16 bpp software engine. * Change image loader module API to take any Image_Entry. Same goes for evas_common_image_premul and evas_common_image_set_alpha_sparse. * Use new eet API: eet_data_image_read_to_surface. SVN revision: 34728
2008-06-03 02:09:39 -07:00
if ((has_alpha) && (im->im->cache_entry.flags.alpha)) return image;
else if ((!has_alpha) && (!im->im->cache_entry.flags.alpha)) return image;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
if (im->references > 1)
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
{
Evas_GL_Image *im_new;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
remove segv in ghl engine with native surfaces if data is null! SVN revision: 51635
2010-08-25 02:29:56 -07:00
im_new = evas_gl_common_image_new_from_copied_data
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
(im->gc, im->im->cache_entry.w, im->im->cache_entry.h,
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
im->im->image.data,
eng_image_alpha_get(data, image),
eng_image_colorspace_get(data, image));
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
if (!im_new) return im;
evas_gl_common_image_free(im);
im = im_new;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
}
else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
fix alpha set/unset on image obj in gl engine. SVN revision: 46344
2010-02-21 07:49:44 -08:00
return evas_gl_common_image_alpha_set(im, has_alpha ? 1 : 0);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// im->im->cache_entry.flags.alpha = has_alpha ? 1 : 0;
// return image;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
}
hmmm after some talking - for now put the transform patch on hold - we need tyo fix up some of these breaks first and there isn't a lot of time devoted to this. so revert this. it's in svn history so we can dig it out any time we like. SVN revision: 37453
2008-11-04 01:19:35 -08:00
static void *
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_border_set(void *data __UNUSED__, void *image, int l __UNUSED__, int r __UNUSED__, int t __UNUSED__, int b __UNUSED__)
hmmm after some talking - for now put the transform patch on hold - we need tyo fix up some of these breaks first and there isn't a lot of time devoted to this. so revert this. it's in svn history so we can dig it out any time we like. SVN revision: 37453
2008-11-04 01:19:35 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
//
// re = (Render_Engine *)data;
hmmm after some talking - for now put the transform patch on hold - we need tyo fix up some of these breaks first and there isn't a lot of time devoted to this. so revert this. it's in svn history so we can dig it out any time we like. SVN revision: 37453
2008-11-04 01:19:35 -08:00
return image;
}
static void
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_border_get(void *data __UNUSED__, void *image __UNUSED__, int *l __UNUSED__, int *r __UNUSED__, int *t __UNUSED__, int *b __UNUSED__)
hmmm after some talking - for now put the transform patch on hold - we need tyo fix up some of these breaks first and there isn't a lot of time devoted to this. so revert this. it's in svn history so we can dig it out any time we like. SVN revision: 37453
2008-11-04 01:19:35 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
//
// re = (Render_Engine *)data;
hmmm after some talking - for now put the transform patch on hold - we need tyo fix up some of these breaks first and there isn't a lot of time devoted to this. so revert this. it's in svn history so we can dig it out any time we like. SVN revision: 37453
2008-11-04 01:19:35 -08:00
}
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
static char *
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_comment_get(void *data __UNUSED__, void *image, char *key __UNUSED__)
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
Evas_GL_Image *im;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image) return NULL;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
im = image;
some more cleanups - issed protecting 1 or 2 calls. gl still doesnt work tho :) not on fglrx. SVN revision: 45388
2010-01-21 04:43:53 -08:00
if (!im->im) return NULL;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
return im->im->info.comment;
}
static char *
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_format_get(void *data __UNUSED__, void *image)
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Render_Engine *re;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
Evas_GL_Image *im;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// re = (Render_Engine *)data;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
im = image;
return NULL;
}
static void
eng_image_colorspace_set(void *data, void *image, int cspace)
{
Render_Engine *re;
Evas_GL_Image *im;
remove trailing spaces SVN revision: 39117
2009-02-21 00:19:58 -08:00
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image) return;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
im = image;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (im->native.data) return;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
/* FIXME: can move to gl_common */
if (im->cs.space == cspace) return;
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
eng_window_use(re->win);
cedric's cache changes patch SVN revision: 34253
2008-04-11 17:32:30 -07:00
evas_cache_image_colorspace(&im->im->cache_entry, cspace);
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
switch (cspace)
{
case EVAS_COLORSPACE_ARGB8888:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
if (im->cs.data)
{
if (!im->cs.no_free) free(im->cs.data);
im->cs.data = NULL;
im->cs.no_free = 0;
}
break;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
case EVAS_COLORSPACE_YCBCR422P601_PL:
case EVAS_COLORSPACE_YCBCR422P709_PL:
evas: add YUY2 shader to GL engine. TODO: add NV12 and NV12T to evas. SVN revision: 62721
2011-08-23 08:13:40 -07:00
case EVAS_COLORSPACE_YCBCR422601_PL:
evas: add NV12 and MT12 colorspace. MT12 is has documented in Linux videodev documentation a 64 * 32 macro block tiled colorspace format used on Samsung hardware. SVN revision: 62967
2011-08-29 13:56:48 -07:00
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
if (im->tex) evas_gl_common_texture_free(im->tex);
im->tex = NULL;
if (im->cs.data)
{
if (!im->cs.no_free) free(im->cs.data);
}
if (im->im->cache_entry.h > 0)
im->cs.data =
calloc(1, im->im->cache_entry.h * sizeof(unsigned char *) * 2);
else
im->cs.data = NULL;
im->cs.no_free = 0;
break;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
default:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
abort();
break;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
}
im->cs.space = cspace;
}
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
/////////////////////////////////////////////////////////////////////////
//
//
typedef struct _Native Native;
struct _Native
{
Evas_Native_Surface ns;
Pixmap pixmap;
Visual *visual;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
gles - update on t2pixmap SVN revision: 45681
2010-01-28 21:32:51 -08:00
void *egl_surface;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#else
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
void *fbc;
XID glx_pixmap;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#endif
};
ok. work on native pixmap suppport. have problmes - not sure why. see comments (create/destory glx pixmap needed for updates to work, but this makes rendering dead-slow. without it rendering is fast, but updates dont happen (useless). anyone know why glxcreatepixmap is needed as well as bindteximage+release (and destroy pixmap) vs just bind/unbind? SVN revision: 45508
2010-01-23 21:11:54 -08:00
// FIXME: this is enabled so updates happen - but its SLOOOOOOOOOOOOOOOW
// (i am sure this is the reason) not to mention seemingly superfluous. but
// i need to enable it for it to work on fglrx at least. havent tried nvidia.
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
//
ok. work on native pixmap suppport. have problmes - not sure why. see comments (create/destory glx pixmap needed for updates to work, but this makes rendering dead-slow. without it rendering is fast, but updates dont happen (useless). anyone know why glxcreatepixmap is needed as well as bindteximage+release (and destroy pixmap) vs just bind/unbind? SVN revision: 45508
2010-01-23 21:11:54 -08:00
// why is this the case? does anyone know? has anyone tried it on other gfx
// drivers?
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
//
more complete gl-texture-pixmap handling, but still is broken on fglrx. hmmm. SVN revision: 45750
2010-01-30 18:50:01 -08:00
//#define GLX_TEX_PIXMAP_RECREATE 1
ok. work on native pixmap suppport. have problmes - not sure why. see comments (create/destory glx pixmap needed for updates to work, but this makes rendering dead-slow. without it rendering is fast, but updates dont happen (useless). anyone know why glxcreatepixmap is needed as well as bindteximage+release (and destroy pixmap) vs just bind/unbind? SVN revision: 45508
2010-01-23 21:11:54 -08:00
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
static void
_native_bind_cb(void *data, void *image)
{
Evas_GL_Image *im = image;
Native *n = im->native.data;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
{
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (n->egl_surface)
{
if (glsym_glEGLImageTargetTexture2DOES)
{
glsym_glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, n->egl_surface);
if (eglGetError() != EGL_SUCCESS)
ERR("glEGLImageTargetTexture2DOES() failed.");
}
else
ERR("Try glEGLImageTargetTexture2DOES on EGL with no support");
}
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#else
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
Render_Engine *re = data;
if (glsym_glXBindTexImage)
{
glsym_glXBindTexImage(re->win->disp, n->glx_pixmap,
GLX_FRONT_LEFT_EXT, NULL);
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
}
else
ERR("Try glXBindTexImage on GLX with no support");
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
# endif
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
else if (n->ns.type == EVAS_NATIVE_SURFACE_OPENGL)
{
glBindTexture(GL_TEXTURE_2D, n->ns.data.opengl.texture_id);
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
}
gles warning-- SVN revision: 58514
2011-04-08 21:13:21 -07:00
return;
data = NULL;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
}
static void
_native_unbind_cb(void *data, void *image)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
Evas_GL_Image *im = image;
Native *n = im->native.data;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
{
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// nothing
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#else
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
Render_Engine *re = data;
if (glsym_glXReleaseTexImage)
{
glsym_glXReleaseTexImage(re->win->disp, n->glx_pixmap,
GLX_FRONT_LEFT_EXT);
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
}
else
ERR("Try glXReleaseTexImage on GLX with no support");
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
# endif
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
else if (n->ns.type == EVAS_NATIVE_SURFACE_OPENGL)
{
glBindTexture(GL_TEXTURE_2D, 0);
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
}
gles warning-- SVN revision: 58514
2011-04-08 21:13:21 -07:00
return;
data = NULL;
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
}
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
static void
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
_native_free_cb(void *data, void *image)
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
Render_Engine *re = data;
Evas_GL_Image *im = image;
Native *n = im->native.data;
uint32_t pmid, texid;
change native api to allow for other types of native data like texture id's, fbo's etc. too - at least it's versioned now. SVN revision: 55315
2010-12-05 23:09:51 -08:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
{
pmid = n->pixmap;
eina_hash_del(re->win->gl_context->shared->native_pm_hash, &pmid, im);
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (n->egl_surface)
{
if (glsym_eglDestroyImage)
{
glsym_eglDestroyImage(re->win->egl_disp,
n->egl_surface);
if (eglGetError() != EGL_SUCCESS)
ERR("eglDestroyImage() failed.");
}
else
ERR("Try eglDestroyImage on EGL with no support");
}
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#else
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (n->glx_pixmap)
{
if (im->native.loose)
{
if (glsym_glXReleaseTexImage)
{
glsym_glXReleaseTexImage(re->win->disp, n->glx_pixmap,
GLX_FRONT_LEFT_EXT);
lots of gl error catching.. if gl errors happen. it's a #defined macro so it can be removed. SVN revision: 46233
2010-02-16 20:21:59 -08:00
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
else
ERR("Try glXReleaseTexImage on GLX with no support");
}
if (glsym_glXDestroyPixmap)
{
glsym_glXDestroyPixmap(re->win->disp, n->glx_pixmap);
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
}
else
ERR("Try glXDestroyPixmap on GLX with no support");
n->glx_pixmap = 0;
}
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
# endif
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
else if (n->ns.type == EVAS_NATIVE_SURFACE_OPENGL)
{
texid = n->ns.data.opengl.texture_id;
eina_hash_del(re->win->gl_context->shared->native_tex_hash, &texid, im);
}
im->native.data = NULL;
im->native.func.data = NULL;
im->native.func.bind = NULL;
im->native.func.unbind = NULL;
im->native.func.free = NULL;
free(n);
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
}
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
static void *
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
eng_image_native_set(void *data, void *image, void *native)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
Render_Engine *re = (Render_Engine *)data;
Evas_Native_Surface *ns = native;
Evas_GL_Image *im = image, *im2 = NULL;
Visual *vis = NULL;
Pixmap pm = 0;
Native *n = NULL;
uint32_t pmid, texid;
unsigned int tex = 0;
unsigned int fbo = 0;
if (!im)
{
if ((!ns) && (ns->type == EVAS_NATIVE_SURFACE_OPENGL))
{
im = evas_gl_common_image_new_from_data(re->win->gl_context,
ns->data.opengl.w,
ns->data.opengl.h,
NULL, 1,
EVAS_COLORSPACE_ARGB8888);
}
else
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return NULL;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
if (ns)
{
if (ns->type == EVAS_NATIVE_SURFACE_X11)
{
vis = ns->data.x11.visual;
pm = ns->data.x11.pixmap;
if (im->native.data)
{
Evas_Native_Surface *ens = im->native.data;
if ((ens->data.x11.visual == vis) &&
(ens->data.x11.pixmap == pm))
return im;
}
}
else if (ns->type == EVAS_NATIVE_SURFACE_OPENGL)
{
tex = ns->data.opengl.texture_id;
fbo = ns->data.opengl.framebuffer_id;
if (im->native.data)
{
Evas_Native_Surface *ens = im->native.data;
if ((ens->data.opengl.texture_id == tex) &&
(ens->data.opengl.framebuffer_id == fbo))
return im;
}
}
}
if ((!ns) && (!im->native.data)) return im;
eng_window_use(re->win);
if (im->native.data)
{
if (im->native.func.free)
im->native.func.free(im->native.func.data, im);
evas_gl_common_image_native_disable(im);
}
if (!ns) return im;
if (ns->type == EVAS_NATIVE_SURFACE_X11)
{
pmid = pm;
im2 = eina_hash_find(re->win->gl_context->shared->native_pm_hash, &pmid);
if (im2 == im) return im;
if (im2)
{
n = im2->native.data;
if (n)
{
evas_gl_common_image_ref(im2);
evas_gl_common_image_free(im);
return im2;
}
}
}
else if (ns->type == EVAS_NATIVE_SURFACE_OPENGL)
{
texid = tex;
im2 = eina_hash_find(re->win->gl_context->shared->native_tex_hash, &texid);
if (im2 == im) return im;
if (im2)
{
n = im2->native.data;
if (n)
{
evas_gl_common_image_ref(im2);
evas_gl_common_image_free(im);
return im2;
}
}
}
im2 = evas_gl_common_image_new_from_data(re->win->gl_context,
im->w, im->h, NULL, im->alpha,
EVAS_COLORSPACE_ARGB8888);
evas_gl_common_image_free(im);
im = im2;
if (ns->type == EVAS_NATIVE_SURFACE_X11)
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
if (native)
{
n = calloc(1, sizeof(Native));
if (n)
{
EGLConfig egl_config;
int config_attrs[20];
int num_config, i = 0;
eina_hash_add(re->win->gl_context->shared->native_pm_hash, &pmid, im);
config_attrs[i++] = EGL_RED_SIZE;
config_attrs[i++] = 8;
config_attrs[i++] = EGL_GREEN_SIZE;
config_attrs[i++] = 8;
config_attrs[i++] = EGL_BLUE_SIZE;
config_attrs[i++] = 8;
config_attrs[i++] = EGL_ALPHA_SIZE;
config_attrs[i++] = 8;
config_attrs[i++] = EGL_DEPTH_SIZE;
config_attrs[i++] = 0;
config_attrs[i++] = EGL_STENCIL_SIZE;
config_attrs[i++] = 0;
config_attrs[i++] = EGL_RENDERABLE_TYPE;
config_attrs[i++] = EGL_OPENGL_ES2_BIT;
config_attrs[i++] = EGL_SURFACE_TYPE;
config_attrs[i++] = EGL_PIXMAP_BIT;
config_attrs[i++] = EGL_NONE;
if (!eglChooseConfig(re->win->egl_disp, config_attrs,
&egl_config, 1, &num_config))
ERR("eglChooseConfig() failed for pixmap 0x%x, num_config = %i", (unsigned int)pm, num_config);
memcpy(&(n->ns), ns, sizeof(Evas_Native_Surface));
n->pixmap = pm;
n->visual = vis;
if (glsym_eglCreateImage)
n->egl_surface = glsym_eglCreateImage(re->win->egl_disp,
EGL_NO_CONTEXT,
EGL_NATIVE_PIXMAP_KHR,
(void *)pm,
NULL);
else
ERR("Try eglCreateImage on EGL with no support");
if (!n->egl_surface)
ERR("eglCreatePixmapSurface() for 0x%x failed", (unsigned int)pm);
im->native.yinvert = 1;
im->native.loose = 0;
im->native.data = n;
im->native.func.data = re;
im->native.func.bind = _native_bind_cb;
im->native.func.unbind = _native_unbind_cb;
im->native.func.free = _native_free_cb;
im->native.target = GL_TEXTURE_2D;
im->native.mipmap = 0;
evas_gl_common_image_native_enable(im);
}
}
#else
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
if (native)
{
int dummy;
unsigned int w, h, depth = 32, border;
Window wdummy;
// fixme: round trip :(
XGetGeometry(re->win->disp, pm, &wdummy, &dummy, &dummy,
&w, &h, &border, &depth);
n = calloc(1, sizeof(Native));
if (n)
{
int pixmap_att[20];
unsigned int target = 0;
unsigned int i = 0;
eina_hash_add(re->win->gl_context->shared->native_pm_hash, &pmid, im);
if ((re->win->depth_cfg[depth].tex_target &
GLX_TEXTURE_2D_BIT_EXT)
// && (1) // we assume npo2 for now
// size is pow2 || mnpo2 supported
)
target = GLX_TEXTURE_2D_EXT;
else if ((re->win->depth_cfg[depth].tex_target &
GLX_TEXTURE_RECTANGLE_BIT_EXT))
{
ERR("rect!!! (not handled)");
target = GLX_TEXTURE_RECTANGLE_EXT;
}
if (!target)
{
ERR("broken text-from-pixmap");
if (!(re->win->depth_cfg[depth].tex_target &
GLX_TEXTURE_2D_BIT_EXT))
target = GLX_TEXTURE_RECTANGLE_EXT;
else if (!(re->win->depth_cfg[depth].tex_target &
GLX_TEXTURE_RECTANGLE_BIT_EXT))
target = GLX_TEXTURE_2D_EXT;
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
pixmap_att[i++] = GLX_TEXTURE_FORMAT_EXT;
pixmap_att[i++] = re->win->depth_cfg[depth].tex_format;
pixmap_att[i++] = GLX_MIPMAP_TEXTURE_EXT;
pixmap_att[i++] = re->win->depth_cfg[depth].mipmap;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (target)
{
pixmap_att[i++] = GLX_TEXTURE_TARGET_EXT;
pixmap_att[i++] = target;
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
pixmap_att[i++] = 0;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
memcpy(&(n->ns), ns, sizeof(Evas_Native_Surface));
n->pixmap = pm;
n->visual = vis;
n->fbc = re->win->depth_cfg[depth].fbc;
if (glsym_glXCreatePixmap)
n->glx_pixmap = glsym_glXCreatePixmap(re->win->disp,
n->fbc,
n->pixmap,
pixmap_att);
else
ERR("Try glXCreatePixmap on GLX with no support");
if (n->glx_pixmap)
{
// printf("%p: new native texture for %x | %4i x %4i @ %2i = %p\n",
// n, pm, w, h, depth, n->glx_pixmap);
if (!target)
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ERR("no target :(");
if (glsym_glXQueryDrawable)
glsym_glXQueryDrawable(re->win->disp,
n->pixmap,
GLX_TEXTURE_TARGET_EXT,
&target);
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
}
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
if (target == GLX_TEXTURE_2D_EXT)
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
im->native.target = GL_TEXTURE_2D;
im->native.mipmap = re->win->depth_cfg[depth].mipmap;
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
}
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
# ifdef GL_TEXTURE_RECTANGLE_ARB
else if (target == GLX_TEXTURE_RECTANGLE_EXT)
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
im->native.target = GL_TEXTURE_RECTANGLE_ARB;
im->native.mipmap = 0;
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
}
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
# endif
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
else
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
im->native.target = GL_TEXTURE_2D;
im->native.mipmap = 0;
ERR("still unknown target");
add indirect engine option - and do glsym for glxcreatepixmap and friends. SVN revision: 46167
2010-02-14 07:12:39 -08:00
}
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
else
ERR("GLX Pixmap create fail");
im->native.yinvert = re->win->depth_cfg[depth].yinvert;
im->native.loose = re->win->detected.loose_binding;
im->native.data = n;
im->native.func.data = re;
im->native.func.bind = _native_bind_cb;
im->native.func.unbind = _native_unbind_cb;
im->native.func.free = _native_free_cb;
evas_gl_common_image_native_enable(im);
}
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
# endif
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
else if (ns->type == EVAS_NATIVE_SURFACE_OPENGL)
{
if (native)
{
n = calloc(1, sizeof(Native));
if (n)
{
memcpy(&(n->ns), ns, sizeof(Evas_Native_Surface));
eina_hash_add(re->win->gl_context->shared->native_tex_hash, &texid, im);
n->pixmap = 0;
n->visual = 0;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
n->egl_surface = 0;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
n->fbc = 0;
n->glx_pixmap = 0;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#endif
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
im->native.yinvert = 0;
im->native.loose = 0;
im->native.data = n;
im->native.func.data = re;
im->native.func.bind = _native_bind_cb;
im->native.func.unbind = _native_unbind_cb;
im->native.func.free = _native_free_cb;
im->native.target = GL_TEXTURE_2D;
im->native.mipmap = 0;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// FIXME: need to implement mapping sub texture regions
// x, y, w, h for possible texture atlasing
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
evas_gl_common_image_native_enable(im);
}
}
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
}
re-jig native surface stuff to share the same gl image between multiple instances of the same pixmap. SVN revision: 50758
2010-08-02 23:09:53 -07:00
return im;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
}
static void *
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_native_get(void *data __UNUSED__, void *image)
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
{
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
Evas_GL_Image *im = image;
Native *n;
if (!im) return NULL;
n = im->native.data;
if (!n) return NULL;
return &(n->ns);
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
}
disable evas filter code. buggy. doesn't work right. SVN revision: 59898
2011-06-02 03:40:43 -07:00
#if 0 // filtering disabled
Evas: Filters: More work, proudly supported by Samsung. Filters! So now you can apply a whole host of cheesy visual effects to objects at runtime. This is the first commit, there are a couple of more to come as I tweak the filters, and fix blur with GL[1]. Please direct bugs to me nash@nash.id.au. [1] You'd think shaders would be good at this.. but no, generic blur and GL are like trying to get an apple product to work with Linux. SVN revision: 58726
2011-04-18 22:47:56 -07:00
static void
eng_image_draw_filtered(void *data, void *context, void *surface,
more bad code - why pass in void * image and data? sero point.. and it totally is out of step with the rest of the api for gl_common.. that alone would tell you "dont so that". ugh. more filter fixes. SVN revision: 58746
2011-04-20 01:05:23 -07:00
void *image, Evas_Filter_Info *filter)
Evas: Filters: More work, proudly supported by Samsung. Filters! So now you can apply a whole host of cheesy visual effects to objects at runtime. This is the first commit, there are a couple of more to come as I tweak the filters, and fix blur with GL[1]. Please direct bugs to me nash@nash.id.au. [1] You'd think shaders would be good at this.. but no, generic blur and GL are like trying to get an apple product to work with Linux. SVN revision: 58726
2011-04-18 22:47:56 -07:00
{
Render_Engine *re = data;
if (!image) return;
eng_window_use(re->win);
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
re->win->gl_context->dc = context;
more bad code - why pass in void * image and data? sero point.. and it totally is out of step with the rest of the api for gl_common.. that alone would tell you "dont so that". ugh. more filter fixes. SVN revision: 58746
2011-04-20 01:05:23 -07:00
evas_gl_common_filter_draw(re->win->gl_context, image, filter);
Evas: Filters: More work, proudly supported by Samsung. Filters! So now you can apply a whole host of cheesy visual effects to objects at runtime. This is the first commit, there are a couple of more to come as I tweak the filters, and fix blur with GL[1]. Please direct bugs to me nash@nash.id.au. [1] You'd think shaders would be good at this.. but no, generic blur and GL are like trying to get an apple product to work with Linux. SVN revision: 58726
2011-04-18 22:47:56 -07:00
}
static Filtered_Image *
eng_image_filtered_get(void *im, uint8_t *key, size_t keylen)
{
return evas_gl_common_image_filtered_get(im, key, keylen);
}
static Filtered_Image *
eng_image_filtered_save(void *im, void *fim, uint8_t *key, size_t keylen)
{
return evas_gl_common_image_filtered_save(im, fim, key, keylen);
}
static void
eng_image_filtered_free(void *im, Filtered_Image *fim)
{
evas_gl_common_image_filtered_free(im, fim);
}
disable evas filter code. buggy. doesn't work right. SVN revision: 59898
2011-06-02 03:40:43 -07:00
#endif
Evas: Filters: More work, proudly supported by Samsung. Filters! So now you can apply a whole host of cheesy visual effects to objects at runtime. This is the first commit, there are a couple of more to come as I tweak the filters, and fix blur with GL[1]. Please direct bugs to me nash@nash.id.au. [1] You'd think shaders would be good at this.. but no, generic blur and GL are like trying to get an apple product to work with Linux. SVN revision: 58726
2011-04-18 22:47:56 -07:00
native surface support lives - for GL (GLX) only. it works - or seemingly does in my test casses. doesn't work for compositing though! don't know why. SVN revision: 45383
2010-01-21 00:44:11 -08:00
//
//
/////////////////////////////////////////////////////////////////////////
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
static void *
Add some missing const SVN revision: 28555
2007-03-04 08:19:32 -08:00
eng_image_load(void *data, const char *file, const char *key, int *error, Evas_Image_Load_Opts *lo)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
re = (Render_Engine *)data;
fix evas image loading error reporting. Evas image load was always reporint "generic" error, since it was disconnected from actual loader modules. This commit will break the module loader API (as it's restricted to inside Evas, this should be no problem). The return was turned into "Eina_Bool" for clarity, while an extra "int *error" is responsible to report errors. This approach was choosen to force compiler warnings and to try avoid mistakes as EINA_FALSE == EVAS_LOAD_ERROR_NONE and thus we'd get opposite behavior if something slips. Most loaders play well, except by eet that does not provide means to know if the file open failed due missing file, incorrect format or corrupted file :-( Please report any issues. I added eina_log debugging to loader functions, just run your Evas application as: EINA_LOG_LEVELS=evas_main:4 your_app SVN revision: 44666
2009-12-22 15:11:57 -08:00
*error = EVAS_LOAD_ERROR_NONE;
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
fix evas image loading error reporting. Evas image load was always reporint "generic" error, since it was disconnected from actual loader modules. This commit will break the module loader API (as it's restricted to inside Evas, this should be no problem). The return was turned into "Eina_Bool" for clarity, while an extra "int *error" is responsible to report errors. This approach was choosen to force compiler warnings and to try avoid mistakes as EINA_FALSE == EVAS_LOAD_ERROR_NONE and thus we'd get opposite behavior if something slips. Most loaders play well, except by eet that does not provide means to know if the file open failed due missing file, incorrect format or corrupted file :-( Please report any issues. I added eina_log debugging to loader functions, just run your Evas application as: EINA_LOG_LEVELS=evas_main:4 your_app SVN revision: 44666
2009-12-22 15:11:57 -08:00
return evas_gl_common_image_load(re->win->gl_context, file, key, lo, error);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
eng_image_new_from_data(void *data, int w, int h, DATA32 *image_data, int alpha, int cspace)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
return evas_gl_common_image_new_from_data(re->win->gl_context, w, h, image_data, alpha, cspace);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
eng_image_new_from_copied_data(void *data, int w, int h, DATA32 *image_data, int alpha, int cspace)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
return evas_gl_common_image_new_from_copied_data(re->win->gl_context, w, h, image_data, alpha, cspace);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_image_free(void *data, void *image)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image) return;
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
evas_gl_common_image_free(image);
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_size_get(void *data __UNUSED__, void *image, int *w, int *h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image)
{
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
*w = 0;
*h = 0;
return;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
}
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (w) *w = ((Evas_GL_Image *)image)->w;
if (h) *h = ((Evas_GL_Image *)image)->h;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_image_size_set(void *data, void *image, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
Evas_GL_Image *im = image;
Evas_GL_Image *im_old;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (!im) return NULL;
if (im->native.data)
{
im->w = w;
im->h = h;
return image;
}
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
eng_window_use(re->win);
fix 2 unimplemented bits in dynamic texture stuff. SVN revision: 51378
2010-08-18 20:30:47 -07:00
if ((im->tex) && (im->tex->pt->dyn.img))
{
evas_gl_common_texture_free(im->tex);
im->tex = NULL;
fix for dyn image size change. SVN revision: 53180
2010-10-07 22:11:32 -07:00
im->w = w;
im->h = h;
fix 2 unimplemented bits in dynamic texture stuff. SVN revision: 51378
2010-08-18 20:30:47 -07:00
im->tex = evas_gl_common_texture_dynamic_new(im->gc, im);
return image;
}
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
im_old = image;
evas: add NV12 and MT12 colorspace. MT12 is has documented in Linux videodev documentation a 64 * 32 macro block tiled colorspace format used on Samsung hardware. SVN revision: 62967
2011-08-29 13:56:48 -07:00
switch (eng_image_colorspace_get(data, image))
{
case EVAS_COLORSPACE_YCBCR422P601_PL:
case EVAS_COLORSPACE_YCBCR422P709_PL:
case EVAS_COLORSPACE_YCBCR422601_PL:
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
w &= ~0x1;
break;
}
cleanup: internal image information is now unsigned. There is no meaning in negative values for image loading, marking as dirty or size, so image internals (cache, entry) were changed to unsigned, reducing possible errors, particularly with overflow. engines were converted to the new way, but any 3rd party modules will still work as they should be using values >= 0 only anyway. please review. new cases introduced by "comparison between signed and unsigned" were fixed in the modules that used cache_entry or Image_Entry dimensions. SVN revision: 52428
2010-09-18 16:16:25 -07:00
if ((im_old) &&
((int)im_old->im->cache_entry.w == w) &&
((int)im_old->im->cache_entry.h == h))
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
return image;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
if (im_old)
{
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
im = evas_gl_common_image_new(re->win->gl_context, w, h,
eng_image_alpha_get(data, image),
eng_image_colorspace_get(data, image));
/*
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
evas_common_load_image_data_from_file(im_old->im);
if (im_old->im->image->data)
{
evas_common_blit_rectangle(im_old->im, im->im, 0, 0, w, h, 0, 0);
evas_common_cpu_end_opt();
}
*/
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
evas_gl_common_image_free(im_old);
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
}
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
im = evas_gl_common_image_new(re->win->gl_context, w, h, 1, EVAS_COLORSPACE_ARGB8888);
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
return im;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
remove excess tex update on dirty. some formattign and naming too. SVN revision: 44592
2009-12-19 22:23:13 -08:00
eng_image_dirty_region(void *data, void *image, int x, int y, int w, int h)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
Evas_GL_Image *im = image;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image) return NULL;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (im->native.data) return image;
some more cleanups - issed protecting 1 or 2 calls. gl still doesnt work tho :) not on fglrx. SVN revision: 45388
2010-01-21 04:43:53 -08:00
eng_window_use(re->win);
remove excess tex update on dirty. some formattign and naming too. SVN revision: 44592
2009-12-19 22:23:13 -08:00
evas_gl_common_image_dirty(image, x, y, w, h);
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
return image;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
eng_image_data_get(void *data, void *image, int to_write, DATA32 **image_data, int *err)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
Evas_GL_Image *im;
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
int error;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image)
{
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
*image_data = NULL;
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
if (err) *err = EVAS_LOAD_ERROR_GENERIC;
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
return NULL;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
}
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
im = image;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (im->native.data)
{
*image_data = NULL;
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
if (err) *err = EVAS_LOAD_ERROR_NONE;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
return im;
}
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
eng_window_use(re->win);
evas: correctly handle direct mapping of data for non RGBA case. SVN revision: 63726
2011-09-30 08:43:51 -07:00
if ((im->tex) && (im->tex->pt) && (im->tex->pt->dyn.img) && (im->cs.space == EVAS_COLORSPACE_ARGB8888))
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
{
ooh aznd other part of dyn img patch goes in. SVN revision: 65053
2011-11-10 23:47:25 -08:00
if (im->tex->pt->dyn.checked_out > 0)
{
im->tex->pt->dyn.checked_out++;
*image_data = im->tex->pt->dyn.data;
if (err) *err = EVAS_LOAD_ERROR_NONE;
return im;
}
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
*image_data = im->tex->pt->dyn.data = glsym_eglMapImageSEC(re->win->egl_disp, im->tex->pt->dyn.img);
if (!im->tex->pt->dyn.data)
{
fix dyn image data return due to change i made a little bit ago SVN revision: 65159
2011-11-14 01:27:29 -08:00
if (err) *err = EVAS_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED;
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
fix dyn image data return due to change i made a little bit ago SVN revision: 65159
2011-11-14 01:27:29 -08:00
return im;
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
}
ooh aznd other part of dyn img patch goes in. SVN revision: 65053
2011-11-10 23:47:25 -08:00
im->tex->pt->dyn.checked_out++;
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
if (err) *err = EVAS_LOAD_ERROR_NONE;
return im;
}
#else
oopsie. fix. SVN revision: 51071
2010-08-13 03:39:41 -07:00
if ((im->tex) && (im->tex->pt) && (im->tex->pt->dyn.data))
more work on egl image direct access. SVN revision: 51070
2010-08-13 03:34:51 -07:00
{
*image_data = im->tex->pt->dyn.data;
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
if (err) *err = EVAS_LOAD_ERROR_NONE;
more work on egl image direct access. SVN revision: 51070
2010-08-13 03:34:51 -07:00
return im;
}
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
#endif
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] evas gl engine's texture creation Hello. 1. _pool_tex_dynamic_new function, it didn’t set pt to NULL when secsym_eglCreateImage function failed. In this case, it returns wrong pt pointer and it has possibility to make crash. So I add free pt code and return NULL code into _pool_tex_dynamic_new function. 2. I modified eng_image_data_get of gl engine. If Evas_GL_Image's texture creation failed and evas_gl_image's cache image was droped, Im->im can be NULL. So I add check code. Example: evas_gl_common_image_content_hint_set 1) EVAS_IMAGE_CONTENT_HINT_DYNAMIC , it drop cache image 2) if evas_gl_common_texture_dynamic_new failed 3) then, im->im =NULL, im->tex=NULL In this situation, if application call's evas_object_image_data_get function, It make crash in evas_cache_image_load_data function. 3. I think function's related with evas_object's engine data have to be return NULL if it failed. If function's returns null, evas object code can handle error more easily. But evas object's code was implemented differently each case. Does my suggestion right? I add engine data null check code to evas_object_image based on upper consumtion. If it is wrong , the patch code related with evas object image have to be removed. If it is right , I will survey other evas object type also. SVN revision: 62775
2011-08-24 21:48:45 -07:00
/* Engine can be fail to create texture after cache drop like eng_image_content_hint_set function,
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
so it is need to add code which check im->im's NULL value*/
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] evas gl engine's texture creation Hello. 1. _pool_tex_dynamic_new function, it didn’t set pt to NULL when secsym_eglCreateImage function failed. In this case, it returns wrong pt pointer and it has possibility to make crash. So I add free pt code and return NULL code into _pool_tex_dynamic_new function. 2. I modified eng_image_data_get of gl engine. If Evas_GL_Image's texture creation failed and evas_gl_image's cache image was droped, Im->im can be NULL. So I add check code. Example: evas_gl_common_image_content_hint_set 1) EVAS_IMAGE_CONTENT_HINT_DYNAMIC , it drop cache image 2) if evas_gl_common_texture_dynamic_new failed 3) then, im->im =NULL, im->tex=NULL In this situation, if application call's evas_object_image_data_get function, It make crash in evas_cache_image_load_data function. 3. I think function's related with evas_object's engine data have to be return NULL if it failed. If function's returns null, evas object code can handle error more easily. But evas object's code was implemented differently each case. Does my suggestion right? I add engine data null check code to evas_object_image based on upper consumtion. If it is wrong , the patch code related with evas object image have to be removed. If it is right , I will survey other evas object type also. SVN revision: 62775
2011-08-24 21:48:45 -07:00
if (!im->im)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
{
*image_data = NULL;
if (err) *err = EVAS_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED;
return NULL;
}
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] evas gl engine's texture creation Hello. 1. _pool_tex_dynamic_new function, it didn’t set pt to NULL when secsym_eglCreateImage function failed. In this case, it returns wrong pt pointer and it has possibility to make crash. So I add free pt code and return NULL code into _pool_tex_dynamic_new function. 2. I modified eng_image_data_get of gl engine. If Evas_GL_Image's texture creation failed and evas_gl_image's cache image was droped, Im->im can be NULL. So I add check code. Example: evas_gl_common_image_content_hint_set 1) EVAS_IMAGE_CONTENT_HINT_DYNAMIC , it drop cache image 2) if evas_gl_common_texture_dynamic_new failed 3) then, im->im =NULL, im->tex=NULL In this situation, if application call's evas_object_image_data_get function, It make crash in evas_cache_image_load_data function. 3. I think function's related with evas_object's engine data have to be return NULL if it failed. If function's returns null, evas object code can handle error more easily. But evas object's code was implemented differently each case. Does my suggestion right? I add engine data null check code to evas_object_image based on upper consumtion. If it is wrong , the patch code related with evas object image have to be removed. If it is right , I will survey other evas object type also. SVN revision: 62775
2011-08-24 21:48:45 -07:00
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
error = evas_cache_image_load_data(&im->im->cache_entry);
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
switch (im->cs.space)
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
{
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
case EVAS_COLORSPACE_ARGB8888:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
if (to_write)
{
if (im->references > 1)
{
Evas_GL_Image *im_new;
im_new = evas_gl_common_image_new_from_copied_data
(im->gc, im->im->cache_entry.w, im->im->cache_entry.h,
im->im->image.data,
eng_image_alpha_get(data, image),
eng_image_colorspace_get(data, image));
if (!im_new)
{
*image_data = NULL;
if (err) *err = EVAS_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED;
return NULL;
}
evas_gl_common_image_free(im);
im = im_new;
}
else
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
}
*image_data = im->im->image.data;
break;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
case EVAS_COLORSPACE_YCBCR422P601_PL:
case EVAS_COLORSPACE_YCBCR422P709_PL:
evas: add YUY2 shader to GL engine. TODO: add NV12 and NV12T to evas. SVN revision: 62721
2011-08-23 08:13:40 -07:00
case EVAS_COLORSPACE_YCBCR422601_PL:
evas: add NV12 and MT12 colorspace. MT12 is has documented in Linux videodev documentation a 64 * 32 macro block tiled colorspace format used on Samsung hardware. SVN revision: 62967
2011-08-29 13:56:48 -07:00
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
*image_data = im->cs.data;
break;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
default:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
abort();
break;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
}
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
if (err) *err = error;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
return im;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
static void *
make hinting an engine api thnig - engine apis need to be mroe easily updated SVN revision: 20850
2006-02-27 20:07:49 -08:00
eng_image_data_put(void *data, void *image, DATA32 *image_data)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
fix segv added in SVN revision: 27499
2006-12-17 08:46:30 -08:00
Evas_GL_Image *im, *im2;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image) return NULL;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
im = image;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (im->native.data) return image;
oops - soemoen changed the other symbols around while i changed the first set SVN revision: 21063
2006-03-06 18:44:16 -08:00
eng_window_use(re->win);
evas: correctly handle direct mapping of data for non RGBA case. SVN revision: 63726
2011-09-30 08:43:51 -07:00
if ((im->tex) && (im->tex->pt)
&& (im->tex->pt->dyn.data)
&& (im->cs.space == EVAS_COLORSPACE_ARGB8888))
more work on egl image direct access. SVN revision: 51070
2010-08-13 03:34:51 -07:00
{
evas: simplify code at the same time. SVN revision: 64169
2011-10-19 02:04:18 -07:00
int w, h;
ooh aznd other part of dyn img patch goes in. SVN revision: 65053
2011-11-10 23:47:25 -08:00
if (im->tex->pt->dyn.data == image_data)
{
im->tex->pt->dyn.checked_out--;
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
ooh aznd other part of dyn img patch goes in. SVN revision: 65053
2011-11-10 23:47:25 -08:00
if (im->tex->pt->dyn.checked_out == 0)
glsym_eglUnmapImageSEC(re->win->egl_disp, im->tex->pt->dyn.img);
From: 우승수 <om101.woo@samsung.com> Subject: [E-devel] [Patch] Map/Unmap image for zero-copy texture this modifies the zero copy texture feature to map and unmap on get and put data to allow the put to "flush gpu caches". SVN revision: 62493
2011-08-16 00:06:36 -07:00
#endif
ooh aznd other part of dyn img patch goes in. SVN revision: 65053
2011-11-10 23:47:25 -08:00
return image;
}
evas: simplify code at the same time. SVN revision: 64169
2011-10-19 02:04:18 -07:00
w = im->im->cache_entry.w;
h = im->im->cache_entry.h;
im2 = eng_image_new_from_data(data, w, h, image_data,
eng_image_alpha_get(data, image),
eng_image_colorspace_get(data, image));
if (!im2) return im;
evas_gl_common_image_free(im);
im = im2;
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
return im;
more work on egl image direct access. SVN revision: 51070
2010-08-13 03:34:51 -07:00
}
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
switch (im->cs.space)
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
{
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
case EVAS_COLORSPACE_ARGB8888:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
if (image_data != im->im->image.data)
{
int w, h;
w = im->im->cache_entry.w;
h = im->im->cache_entry.h;
im2 = eng_image_new_from_data(data, w, h, image_data,
eng_image_alpha_get(data, image),
eng_image_colorspace_get(data, image));
if (!im2) return im;
evas_gl_common_image_free(im);
im = im2;
}
break;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
case EVAS_COLORSPACE_YCBCR422P601_PL:
case EVAS_COLORSPACE_YCBCR422P709_PL:
evas: add YUY2 shader to GL engine. TODO: add NV12 and NV12T to evas. SVN revision: 62721
2011-08-23 08:13:40 -07:00
case EVAS_COLORSPACE_YCBCR422601_PL:
evas: add NV12 and MT12 colorspace. MT12 is has documented in Linux videodev documentation a 64 * 32 macro block tiled colorspace format used on Samsung hardware. SVN revision: 62967
2011-08-29 13:56:48 -07:00
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
if (image_data != im->cs.data)
{
if (im->cs.data)
{
if (!im->cs.no_free) free(im->cs.data);
}
im->cs.data = image_data;
}
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
break;
not complete yet - actually i need help with the fragment shader. in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3 textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex) are simply getting values from the Ytex - regardless of what i try. grrr. what's up with that? SVN revision: 27495
2006-12-17 07:48:52 -08:00
default:
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
abort();
break;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
}
return im;
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
Add image preloading support. This should work without performance impact for all engine. SVN revision: 36018
2008-09-16 07:52:57 -07:00
static void
* remove 'unused parameter' warnings * i didn't touch glitz engine as it will certainly be disabled later * i'll update windows engines later SVN revision: 39274
2009-02-28 02:08:45 -08:00
eng_image_data_preload_request(void *data __UNUSED__, void *image, const void *target)
Add image preloading support. This should work without performance impact for all engine. SVN revision: 36018
2008-09-16 07:52:57 -07:00
{
Evas_GL_Image *gim = image;
RGBA_Image *im;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (!gim) return;
if (gim->native.data) return;
im = (RGBA_Image *)gim->im;
if (!im) return;
Add image preloading support. This should work without performance impact for all engine. SVN revision: 36018
2008-09-16 07:52:57 -07:00
evas_cache_image_preload_data(&im->cache_entry, target);
}
static void
* remove 'unused parameter' warnings * i didn't touch glitz engine as it will certainly be disabled later * i'll update windows engines later SVN revision: 39274
2009-02-28 02:08:45 -08:00
eng_image_data_preload_cancel(void *data __UNUSED__, void *image, const void *target)
Add image preloading support. This should work without performance impact for all engine. SVN revision: 36018
2008-09-16 07:52:57 -07:00
{
Evas_GL_Image *gim = image;
RGBA_Image *im;
some protection against playing with native surfaces (setting image size doent re-alloc for example) SVN revision: 45385
2010-01-21 01:42:26 -08:00
if (!gim) return;
if (gim->native.data) return;
im = (RGBA_Image *)gim->im;
if (!im) return;
Correctly cancel each image object and not all at once. SVN revision: 38658
2009-01-20 06:56:37 -08:00
evas_cache_image_preload_cancel(&im->cache_entry, target);
Add image preloading support. This should work without performance impact for all engine. SVN revision: 36018
2008-09-16 07:52:57 -07:00
}
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
static void
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
eng_image_draw(void *data, void *context, void *surface, void *image, int src_x, int src_y, int src_w, int src_h, int dst_x, int dst_y, int dst_w, int dst_h, int smooth)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
whitespace SVN revision: 14889
2005-05-21 19:49:50 -07:00
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
re = (Render_Engine *)data;
fix color modulation for gl surfaces. also fix segvs tat can happen. xrender engine is behind now though. can't do yuv surfaces (yet) SVN revision: 27518
2006-12-19 06:12:40 -08:00
if (!image) return;
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if ((gl_direct_img_obj) && (gl_direct_enabled))
{
DBG("Rendering Directly to the window");
evas_object_image_pixels_dirty_set(gl_direct_img_obj, EINA_TRUE);
}
else
{
eng_window_use(re->win);
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
re->win->gl_context->dc = context;
evas_gl_common_image_draw(re->win->gl_context, image,
src_x, src_y, src_w, src_h,
dst_x, dst_y, dst_w, dst_h,
smooth);
}
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
1. scale cache now allows you to hint at the object if its dynamic, static or none (ie default) and the engines actually understand it and use it. 2. fixes to scalecache and cserver too. more toto's done and its now been stress tested by me - and i think cserve is ready to go gold. just enable it with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve (cmd-line options avalable plus cmd-line tol to query settings change on the fly and query statsitics and state) SVN revision: 40536
2009-05-07 06:29:56 -07:00
static void
eng_image_scale_hint_set(void *data __UNUSED__, void *image, int hint)
{
more glue/infra. glue evas api to engine together. gl engine gets stubs. SVN revision: 51028
2010-08-11 23:11:13 -07:00
if (image) evas_gl_common_image_scale_hint_set(image, hint);
}
static int
eng_image_scale_hint_get(void *data __UNUSED__, void *image)
{
Evas_GL_Image *gim = image;
if (!gim) return EVAS_IMAGE_SCALE_HINT_NONE;
return gim->scale_hint;
1. scale cache now allows you to hint at the object if its dynamic, static or none (ie default) and the engines actually understand it and use it. 2. fixes to scalecache and cserver too. more toto's done and its now been stress tested by me - and i think cserve is ready to go gold. just enable it with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve (cmd-line options avalable plus cmd-line tol to query settings change on the fly and query statsitics and state) SVN revision: 40536
2009-05-07 06:29:56 -07:00
}
better text perf - less geometry data for complex text drawing. simpler yuv with matrix. SVN revision: 43487
2009-11-06 03:32:23 -08:00
static void
Evas: GL_X11 engine: Do not set UNUSED on variables that we actually use and remove some extra whitespace between functions. SVN revision: 60153
2011-06-09 12:25:21 -07:00
eng_image_map_draw(void *data, void *context, void *surface, void *image, int npoints, RGBA_Map_Point *p, int smooth, int level)
better text perf - less geometry data for complex text drawing. simpler yuv with matrix. SVN revision: 43487
2009-11-06 03:32:23 -08:00
{
fix actually supporting clip for maps in gl. SVN revision: 52415
2010-09-18 07:23:20 -07:00
Evas_GL_Image *gim = image;
step 1. some map support! images only right now. next. render-to-texture. invasive change right now. SVN revision: 43611
2009-11-11 03:39:25 -08:00
Render_Engine *re;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
step 1. some map support! images only right now. next. render-to-texture. invasive change right now. SVN revision: 43611
2009-11-11 03:39:25 -08:00
re = (Render_Engine *)data;
fix actually supporting clip for maps in gl. SVN revision: 52415
2010-09-18 07:23:20 -07:00
if (!image) return;
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
eng_window_use(re->win);
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
re->win->gl_context->dc = context;
fix most of nash's mess. 2 added aborts that nash has to fix. SVN revision: 56891
2011-02-09 22:52:53 -08:00
if (npoints != 4)
{
evas: fix misspellings Misspellings found by codespell SVN revision: 59822
2011-05-30 09:45:08 -07:00
// FIXME: nash - you didn't fix this
fix most of nash's mess. 2 added aborts that nash has to fix. SVN revision: 56891
2011-02-09 22:52:53 -08:00
abort();
}
fix actually supporting clip for maps in gl. SVN revision: 52415
2010-09-18 07:23:20 -07:00
if ((p[0].x == p[3].x) &&
(p[1].x == p[2].x) &&
(p[0].y == p[1].y) &&
(p[3].y == p[2].y) &&
(p[0].x <= p[1].x) &&
(p[0].y <= p[2].y) &&
(p[0].u == 0) &&
(p[0].v == 0) &&
(p[1].u == (gim->w << FP)) &&
(p[1].v == 0) &&
(p[2].u == (gim->w << FP)) &&
(p[2].v == (gim->h << FP)) &&
(p[3].u == 0) &&
(p[3].v == (gim->h << FP)) &&
(p[0].col == 0xffffffff) &&
(p[1].col == 0xffffffff) &&
(p[2].col == 0xffffffff) &&
(p[3].col == 0xffffffff))
{
int dx, dy, dw, dh;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
fix actually supporting clip for maps in gl. SVN revision: 52415
2010-09-18 07:23:20 -07:00
dx = p[0].x >> FP;
dy = p[0].y >> FP;
dw = (p[2].x >> FP) - dx;
dh = (p[2].y >> FP) - dy;
Evas: Fixed a few 'implicit declaration' warnings. Add missing evas_object_image_source functions. (was giving nasty 'implicit declarations' prior to this change) Add UNUSED to evas_common_map_rgba for npoints variable (wasn't used in that function) Fixed a little formatting in evas_object_main.c Add UNUSED to the eng_image_map_draw function of the gl_x11 engine. (npoints variable not used there) Fixed a little formatting in gl_x11 engine. SVN revision: 56869
2011-02-09 10:39:54 -08:00
eng_image_draw(data, context, surface, image,
0, 0, gim->w, gim->h, dx, dy, dw, dh, smooth);
fix actually supporting clip for maps in gl. SVN revision: 52415
2010-09-18 07:23:20 -07:00
}
else
{
fix most of nash's mess. 2 added aborts that nash has to fix. SVN revision: 56891
2011-02-09 22:52:53 -08:00
evas_gl_common_image_map_draw(re->win->gl_context, image, npoints, p,
smooth, level);
fix actually supporting clip for maps in gl. SVN revision: 52415
2010-09-18 07:23:20 -07:00
}
better text perf - less geometry data for complex text drawing. simpler yuv with matrix. SVN revision: 43487
2009-11-06 03:32:23 -08:00
}
static void *
Evas: GL_X11 engine: Do not set UNUSED on variables that we actually use and remove some extra whitespace between functions. SVN revision: 60153
2011-06-09 12:25:21 -07:00
eng_image_map_surface_new(void *data, int w, int h, int alpha)
better text perf - less geometry data for complex text drawing. simpler yuv with matrix. SVN revision: 43487
2009-11-06 03:32:23 -08:00
{
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
Render_Engine *re;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
re = (Render_Engine *)data;
return evas_gl_common_image_surface_new(re->win->gl_context, w, h, alpha);
better text perf - less geometry data for complex text drawing. simpler yuv with matrix. SVN revision: 43487
2009-11-06 03:32:23 -08:00
}
static void
eng_image_map_surface_free(void *data __UNUSED__, void *surface)
{
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
evas_gl_common_image_free(surface);
better text perf - less geometry data for complex text drawing. simpler yuv with matrix. SVN revision: 43487
2009-11-06 03:32:23 -08:00
}
more glue/infra. glue evas api to engine together. gl engine gets stubs. SVN revision: 51028
2010-08-11 23:11:13 -07:00
static void
eng_image_content_hint_set(void *data __UNUSED__, void *image, int hint)
{
if (image) evas_gl_common_image_content_hint_set(image, hint);
}
1. scale cache now allows you to hint at the object if its dynamic, static or none (ie default) and the engines actually understand it and use it. 2. fixes to scalecache and cserver too. more toto's done and its now been stress tested by me - and i think cserve is ready to go gold. just enable it with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve (cmd-line options avalable plus cmd-line tol to query settings change on the fly and query statsitics and state) SVN revision: 40536
2009-05-07 06:29:56 -07:00
static int
more glue/infra. glue evas api to engine together. gl engine gets stubs. SVN revision: 51028
2010-08-11 23:11:13 -07:00
eng_image_content_hint_get(void *data __UNUSED__, void *image)
1. scale cache now allows you to hint at the object if its dynamic, static or none (ie default) and the engines actually understand it and use it. 2. fixes to scalecache and cserver too. more toto's done and its now been stress tested by me - and i think cserve is ready to go gold. just enable it with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve (cmd-line options avalable plus cmd-line tol to query settings change on the fly and query statsitics and state) SVN revision: 40536
2009-05-07 06:29:56 -07:00
{
more glue/infra. glue evas api to engine together. gl engine gets stubs. SVN revision: 51028
2010-08-11 23:11:13 -07:00
Evas_GL_Image *gim = image;
if (!gim) return EVAS_IMAGE_CONTENT_HINT_NONE;
return gim->content_hint;
1. scale cache now allows you to hint at the object if its dynamic, static or none (ie default) and the engines actually understand it and use it. 2. fixes to scalecache and cserver too. more toto's done and its now been stress tested by me - and i think cserve is ready to go gold. just enable it with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve (cmd-line options avalable plus cmd-line tol to query settings change on the fly and query statsitics and state) SVN revision: 40536
2009-05-07 06:29:56 -07:00
}
improvement to gl engine wrt. caching. SVN revision: 56801
2011-02-08 03:41:38 -08:00
static void
Evas: GL_X11 engine: Do not set UNUSED on variables that we actually use and remove some extra whitespace between functions. SVN revision: 60153
2011-06-09 12:25:21 -07:00
eng_image_cache_flush(void *data)
improvement to gl engine wrt. caching. SVN revision: 56801
2011-02-08 03:41:38 -08:00
{
Render_Engine *re;
int tmp_size;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
improvement to gl engine wrt. caching. SVN revision: 56801
2011-02-08 03:41:38 -08:00
re = (Render_Engine *)data;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
improvement to gl engine wrt. caching. SVN revision: 56801
2011-02-08 03:41:38 -08:00
tmp_size = evas_common_image_get_cache();
evas_common_image_set_cache(0);
evas_common_rgba_image_scalecache_flush();
evas_gl_common_image_cache_flush(re->win->gl_context);
evas_common_image_set_cache(tmp_size);
}
static void
Evas: GL_X11 engine: Do not set UNUSED on variables that we actually use and remove some extra whitespace between functions. SVN revision: 60153
2011-06-09 12:25:21 -07:00
eng_image_cache_set(void *data, int bytes)
improvement to gl engine wrt. caching. SVN revision: 56801
2011-02-08 03:41:38 -08:00
{
Render_Engine *re;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
improvement to gl engine wrt. caching. SVN revision: 56801
2011-02-08 03:41:38 -08:00
re = (Render_Engine *)data;
evas_common_image_set_cache(bytes);
evas_common_rgba_image_scalecache_size_set(bytes);
evas_gl_common_image_cache_flush(re->win->gl_context);
}
static int
eng_image_cache_get(void *data __UNUSED__)
{
return evas_common_image_get_cache();
}
and make dynamic hint actually work when we have zero-copy texture support. fully ok now for argb8888. SVN revision: 51380
2010-08-18 22:18:17 -07:00
static void
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
eng_image_stride_get(void *data __UNUSED__, void *image, int *stride)
fix 2 unimplemented bits in dynamic texture stuff. SVN revision: 51378
2010-08-18 20:30:47 -07:00
{
Evas_GL_Image *im = image;
Evas: GL_X11 engine: Do not set UNUSED on variables that we actually use and remove some extra whitespace between functions. SVN revision: 60153
2011-06-09 12:25:21 -07:00
fix gl stride SVN revision: 52432
2010-09-18 17:28:58 -07:00
if ((im->tex) && (im->tex->pt->dyn.img))
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
*stride = im->tex->pt->dyn.stride;
evas/evas_engine - patched by Seung-Soo Woo <om101.woo@samsung.com> Dear all, eng_image_stride_get() of gl backend get fault stride value. In case of using dynamic image, it get from dyn.w*4. But, dyn.stride was already got from secsym_eglGetImageAttribSEC() in _pool_tex_dynamic_new(). dyn.stride can be changed according to DDK. So, the stride needs to get from dyn.stride. Please find enclosed file. Thanks. SVN revision: 61463
2011-07-17 22:32:06 -07:00
else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
*stride = im->w * 4;
fix 2 unimplemented bits in dynamic texture stuff. SVN revision: 51378
2010-08-18 20:30:47 -07:00
}
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
static void
Evas engines: Adjust all the rest of the engines to use Evas_Font_Set. SVN revision: 59784
2011-05-29 06:56:23 -07:00
eng_font_draw(void *data, void *context, void *surface, Evas_Font_Set *font, int x, int y, int w __UNUSED__, int h __UNUSED__, int ow __UNUSED__, int oh __UNUSED__, const Evas_Text_Props *intl_props)
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
{
Render_Engine *re;
re = (Render_Engine *)data;
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
eng_window_use(re->win);
render-to-texture now is used for evas maps... but only simple cases seem to work. (in ello) elementary stuff seems... less happy. will work on it! also havent done the gles bits. just desktop gl (first port of call for doing/testing). the #ifdefs are ther waiting with fixme's SVN revision: 43653
2009-11-12 23:22:31 -08:00
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
re->win->gl_context->dc = context;
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
{
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
// FIXME: put im into context so we can free it
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
static RGBA_Image *im = NULL;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
if (!im)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
im = (RGBA_Image *)evas_cache_image_empty(evas_common_image_cache_get());
new gl engine. no one uses it anyway. not 100% complete, but much better than the old. and it ALSO does GLES2.0 as well asn GL. SVN revision: 42982
2009-10-09 05:10:27 -07:00
im->cache_entry.w = re->win->w;
im->cache_entry.h = re->win->h;
evas_common_draw_context_font_ext_set(context,
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
re->win->gl_context,
evas_gl_font_texture_new,
evas_gl_font_texture_free,
evas_gl_font_texture_draw);
evas_common_font_draw(im, context, (RGBA_Font *) font, x, y,
Evas engines: Adjust all the rest of the engines to use Evas_Font_Set. SVN revision: 59784
2011-05-29 06:56:23 -07:00
intl_props);
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
evas_common_draw_context_font_ext_set(context,
NULL,
NULL,
NULL,
NULL);
GL engine goes in... its not 100% complete. fonts are sub-optimal. i quickly hooked them in to work at all... SVN revision: 7408
2003-09-04 00:40:34 -07:00
}
code move SVN revision: 6445
2002-11-08 00:02:15 -08:00
}
* evas: gl_x11 window can't support alpha, as drawing rect with alpha=0 is not possible. SVN revision: 41769
2009-08-14 10:11:08 -07:00
static Eina_Bool
actually - we dont need to clear at all. rely on engine alpha returning right value and let evas_render do it. SVN revision: 60748
2011-06-28 01:11:07 -07:00
eng_canvas_alpha_get(void *data, void *info __UNUSED__)
* evas: gl_x11 window can't support alpha, as drawing rect with alpha=0 is not possible. SVN revision: 41769
2009-08-14 10:11:08 -07:00
{
actually - we dont need to clear at all. rely on engine alpha returning right value and let evas_render do it. SVN revision: 60748
2011-06-28 01:11:07 -07:00
Render_Engine *re = (Render_Engine *)data;
return re->win->alpha;
* evas: gl_x11 window can't support alpha, as drawing rect with alpha=0 is not possible. SVN revision: 41769
2009-08-14 10:11:08 -07:00
}
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
static int
_set_internal_config(Render_Engine_GL_Surface *sfc, Evas_GL_Config *cfg)
{
// Also initialize pixel format here as well...
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
switch((int)cfg->color_format)
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
{
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly) I'm submitting a patch that changes the color format for Evas GL. When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8 and etc but it was misleading for some people. It was more of a filler since I couldn't decide on a name. I'm finally changing it to make it more clear. SVN revision: 64491
2011-10-28 04:08:23 -07:00
case EVAS_GL_RGB_888:
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sfc->rt_fmt = GL_RGB;
sfc->rt_internal_fmt = GL_RGB;
break;
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly) I'm submitting a patch that changes the color format for Evas GL. When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8 and etc but it was misleading for some people. It was more of a filler since I couldn't decide on a name. I'm finally changing it to make it more clear. SVN revision: 64491
2011-10-28 04:08:23 -07:00
case EVAS_GL_RGBA_8888:
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sfc->rt_fmt = GL_RGBA;
sfc->rt_internal_fmt = GL_RGBA;
break;
default:
ERR("Invalid Color Format!");
return 0;
}
switch(cfg->depth_bits)
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
{
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
case EVAS_GL_DEPTH_NONE:
break;
case EVAS_GL_DEPTH_BIT_8:
case EVAS_GL_DEPTH_BIT_16:
case EVAS_GL_DEPTH_BIT_24:
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// 24 bit doesn't work... just cover it with 16 for now..
sfc->rb_depth_fmt = GL_DEPTH_COMPONENT16;
#else
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sfc->rb_depth_fmt = GL_DEPTH_COMPONENT;
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
break;
case EVAS_GL_DEPTH_BIT_32:
default:
ERR("Unsupported Depth Bits Format!");
return 0;
}
switch(cfg->stencil_bits)
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
{
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
case EVAS_GL_STENCIL_NONE:
break;
case EVAS_GL_STENCIL_BIT_1:
case EVAS_GL_STENCIL_BIT_2:
case EVAS_GL_STENCIL_BIT_4:
case EVAS_GL_STENCIL_BIT_8:
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sfc->rb_stencil_fmt = GL_STENCIL_INDEX8;
#else
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sfc->rb_stencil_fmt = GL_STENCIL_INDEX;
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
break;
case EVAS_GL_STENCIL_BIT_16:
default:
ERR("Unsupported Stencil Bits Format!");
return 0;
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if (cfg->options_bits)
{
if (cfg->options_bits & EVAS_GL_OPTIONS_DIRECT)
sfc->direct_fb_opt = 1;
// Add other options here...
}
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return 1;
}
static int
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
_create_rt_buffers(Render_Engine *data __UNUSED__,
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Render_Engine_GL_Surface *sfc)
{
// Render Target texture
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glGenTextures(1, &sfc->rt_tex );
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
// Depth RenderBuffer - Create storage here...
if (sfc->depth_bits != EVAS_GL_DEPTH_NONE)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glGenRenderbuffers(1, &sfc->rb_depth);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
// Stencil RenderBuffer - Create Storage here...
if (sfc->stencil_bits != EVAS_GL_STENCIL_NONE)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glGenRenderbuffers(1, &sfc->rb_stencil);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return 1;
}
static int
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
_attach_fbo_surface(Render_Engine *data __UNUSED__,
Render_Engine_GL_Surface *sfc,
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Render_Engine_GL_Context *ctx)
{
int fb_status;
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
2011-10-18 01:13:23 -07:00
// Initialize Texture
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glBindTexture(GL_TEXTURE_2D, sfc->rt_tex );
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, sfc->w, sfc->h, 0,
GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glBindTexture(GL_TEXTURE_2D, 0);
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
2011-10-18 01:13:23 -07:00
// Attach texture to FBO
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glBindFramebuffer(GL_FRAMEBUFFER, ctx->context_fbo);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, sfc->rt_tex, 0);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
// Depth RenderBuffer - Attach it to FBO
if (sfc->depth_bits != EVAS_GL_DEPTH_NONE)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glBindRenderbuffer(GL_RENDERBUFFER, sfc->rb_depth);
glRenderbufferStorage(GL_RENDERBUFFER, sfc->rb_depth_fmt,
sfc->w, sfc->h);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, sfc->rb_depth);
glBindRenderbuffer(GL_RENDERBUFFER, 0);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
// Stencil RenderBuffer - Attach it to FBO
if (sfc->stencil_bits != EVAS_GL_STENCIL_NONE)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glBindRenderbuffer(GL_RENDERBUFFER, sfc->rb_stencil);
glRenderbufferStorage(GL_RENDERBUFFER, sfc->rb_stencil_fmt,
sfc->w, sfc->h);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT,
GL_RENDERBUFFER, sfc->rb_stencil);
glBindRenderbuffer(GL_RENDERBUFFER, 0);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
// Check FBO for completeness
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
fb_status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (fb_status != GL_FRAMEBUFFER_COMPLETE)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
ERR("FBO not complete!");
return 0;
}
return 1;
}
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
2011-10-18 01:13:23 -07:00
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
static void *
eng_gl_surface_create(void *data, void *config, int w, int h)
{
Render_Engine *re;
Render_Engine_GL_Surface *sfc;
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
2011-10-18 01:13:23 -07:00
Render_Engine_GL_Resource *rsc;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
Evas_GL_Config *cfg;
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
int ret;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sfc = calloc(1, sizeof(Render_Engine_GL_Surface));
if (!sfc) return NULL;
re = (Render_Engine *)data;
cfg = (Evas_GL_Config *)config;
sfc->initialized = 0;
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
sfc->fbo_attached = 0;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
sfc->w = w;
sfc->h = h;
sfc->depth_bits = cfg->depth_bits;
sfc->stencil_bits = cfg->stencil_bits;
sfc->rt_tex = 0;
sfc->rb_depth = 0;
sfc->rb_stencil = 0;
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
/* Allow alpha for evas gl direct rendering */
// FIXME!!!: A little out of place for for now...
if (!gl_direct_override)
if (getenv("EVAS_GL_DIRECT_OVERRIDE")) gl_direct_override = 1;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
// Set the internal format based on the config
if (!_set_internal_config(sfc, cfg))
{
ERR("Unsupported Format!");
free(sfc);
return NULL;
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if (sfc->direct_fb_opt)
{
DBG("Enabling Direct rendering to the Evas' window.");
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sfc->direct_sfc = re->win->egl_surface[0];
#else
sfc->direct_sfc = re->win->win;
#endif
}
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
2011-10-18 01:13:23 -07:00
// Create internal resource context if it hasn't been created already
if ((rsc = eina_tls_get(resource_key)) == NULL)
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
{
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
2011-10-18 01:13:23 -07:00
if ((rsc = _create_internal_glue_resources(re)) == NULL)
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
{
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
2011-10-18 01:13:23 -07:00
ERR("Error creating internal resources.");
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
free(sfc);
return NULL;
}
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
2011-10-18 01:13:23 -07:00
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
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
2011-10-18 01:13:23 -07:00
// I'm using evas's original context to create the render target texture
// This is to prevent awkwardness in using native_surface_get() function
// If the rt texture creation is deferred till the context is created and
// make_current called, the user can't call native_surface_get() right
// after the surface is created. hence this is done here using evas' context.
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = eglMakeCurrent(re->win->egl_disp, rsc->surface, rsc->surface, rsc->context);
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
2011-10-18 01:13:23 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = glXMakeCurrent(re->info->info.display, re->win->win, rsc->context);
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
2011-10-18 01:13:23 -07:00
#endif
if (!ret)
{
ERR("xxxMakeCurrent() failed!");
free(sfc);
return NULL;
}
// Create Render texture
if (!_create_rt_buffers(re, sfc))
{
ERR("_create_rt_buffers() failed.");
free(sfc);
return NULL;
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = glXMakeCurrent(re->info->info.display, None, NULL);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
#endif
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
2011-10-18 01:13:23 -07:00
if (!ret)
{
ERR("xxxMakeCurrent() failed!");
free(sfc);
return NULL;
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch I'm attaching a patch that addresses the awkward usage case. It's something that didn't bother me initially but the more I look at it, i think it's a little off. :-) The initial version of the evas_gl that I've submitted had the following use case. evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); // Make current triggers surface texture and FBO to be created evas_gl_make_current(evasgl, sfc, ctx); // Then you can do a surface_get to retrieve the proper texture and set it evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The unnatural thing about this use case is that you have to call the make_current one time in order for evas_gl to generate a surface texture. This is because you need a context to create a texture. Unfortunately, this makes the usage case really awkward. So, instead, I've decided to get rid of the need for calling the make_current by generating a surface texture when evas_gl_surface_create() is called by using the evas' gl context. This works because the newly created context shares resources with evas. in fact, this is what i'm currently doing with surface deletion anyway so I thought this solution was reasonable. Here's how it looks after you get rid of the make_current: evasgl = evas_gl_new(e); sfc = evas_gl_surface_create(...); ctx = evas_gl_context_create(...); evas_gl_native_surface_get(evasgl, sfc, &ns); evas_object_image_native_surface_set(img_obj, &ns); The patch is pretty small and straightforward. SVN revision: 58892
2011-04-25 01:41:36 -07:00
}
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return sfc;
}
static int
eng_gl_surface_destroy(void *data, void *surface)
{
Render_Engine *re;
Render_Engine_GL_Surface *sfc;
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
2011-10-18 01:13:23 -07:00
Render_Engine_GL_Resource *rsc;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
int ret;
re = (Render_Engine *)data;
sfc = (Render_Engine_GL_Surface*)surface;
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
2011-10-18 01:13:23 -07:00
if (!sfc) return 0;
if ((rsc = eina_tls_get(resource_key)) == EINA_FALSE) return 0;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = eglMakeCurrent(re->win->egl_disp, rsc->surface, rsc->surface, rsc->context);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = glXMakeCurrent(re->info->info.display, re->win->win, rsc->context);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#endif
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (!ret)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
ERR("xxxMakeCurrent() failed!");
return 0;
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Reset the Framebuffer binding point
if ((current_evgl_ctx) && (current_evgl_ctx->current_fbo == current_evgl_ctx->context_fbo))
{
//glBindFramebuffer(GL_FRAMEBUFFER, 0);
current_evgl_ctx->current_fbo = 0;
current_evgl_ctx->current_sfc = NULL;
}
// Clear direct rendering flag
gl_direct_enabled = 0;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
// Delete FBO/RBO and Texture here
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
2011-10-18 01:13:23 -07:00
if (sfc->rt_tex)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glDeleteTextures(1, &sfc->rt_tex);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
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
2011-10-18 01:13:23 -07:00
if (sfc->rb_depth)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glDeleteRenderbuffers(1, &sfc->rb_depth);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
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
2011-10-18 01:13:23 -07:00
if (sfc->rb_stencil)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glDeleteRenderbuffers(1, &sfc->rb_stencil);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = glXMakeCurrent(re->info->info.display, None, NULL);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#endif
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (!ret)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
ERR("xxxMakeCurrent() failed!");
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
2011-10-18 01:13:23 -07:00
free(sfc);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return 0;
}
free(sfc);
surface = NULL;
return 1;
}
static void *
eng_gl_context_create(void *data, void *share_context)
{
Render_Engine *re;
Render_Engine_GL_Context *ctx;
Render_Engine_GL_Context *share_ctx;
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
int context_attrs[3];
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
ctx = calloc(1, sizeof(Render_Engine_GL_Context));
if (!ctx) return NULL;
re = (Render_Engine *)data;
share_ctx = (Render_Engine_GL_Context *)share_context;
// Set the share context to Evas' GL context if share_context is NULL.
// Otherwise set it to the given share_context.
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// EGL
context_attrs[0] = EGL_CONTEXT_CLIENT_VERSION;
context_attrs[1] = 2;
context_attrs[2] = EGL_NONE;
if (share_ctx)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ctx->context = eglCreateContext(re->win->egl_disp,
re->win->egl_config,
share_ctx->context, // Share Context
context_attrs);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
else
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ctx->context = eglCreateContext(re->win->egl_disp,
re->win->egl_config,
re->win->egl_context[0], // Evas' GL Context
context_attrs);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (!ctx->context)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ERR("eglCreateContext() fail. code=%#x", eglGetError());
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return NULL;
}
#else
// GLX
if (share_context)
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ctx->context = glXCreateContext(re->info->info.display,
re->win->visualinfo,
share_ctx->context, // Share Context
1);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
else
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ctx->context = glXCreateContext(re->info->info.display,
re->win->visualinfo,
re->win->context, // Evas' GL Context
1);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (!ctx->context)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
ERR("glXCreateContext() fail.");
return NULL;
}
#endif
ctx->initialized = 0;
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
ctx->context_fbo = 0;
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
ctx->current_sfc = NULL;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return ctx;
}
static int
eng_gl_context_destroy(void *data, void *context)
{
Render_Engine *re;
Render_Engine_GL_Context *ctx;
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
2011-10-18 01:13:23 -07:00
Render_Engine_GL_Resource *rsc;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
int ret;
re = (Render_Engine *)data;
ctx = (Render_Engine_GL_Context*)context;
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
2011-10-18 01:13:23 -07:00
if (!ctx) return 0;
if ((rsc = eina_tls_get(resource_key)) == EINA_FALSE) return 0;
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Do a make current with the given context
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = eglMakeCurrent(re->win->egl_disp, rsc->surface,
rsc->surface, ctx->context);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = glXMakeCurrent(re->info->info.display, re->win->win,
ctx->context);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#endif
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (!ret)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
ERR("xxxMakeCurrent() failed!");
return 0;
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Delete the FBO
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
2011-10-18 01:13:23 -07:00
if (ctx->context_fbo)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glDeleteFramebuffers(1, &ctx->context_fbo);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Destroy the Context
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
eglDestroyContext(re->win->egl_disp, ctx->context);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
ctx->context = EGL_NO_CONTEXT;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE,
EGL_NO_SURFACE, EGL_NO_CONTEXT);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glXDestroyContext(re->info->info.display, ctx->context);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
ctx->context = 0;
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = glXMakeCurrent(re->info->info.display, None, NULL);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#endif
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (!ret)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
ERR("xxxMakeCurrent() failed!");
return 0;
}
free(ctx);
context = NULL;
return 1;
}
static int
warning-- SVN revision: 64387
2011-10-25 05:07:56 -07:00
eng_gl_make_current(void *data __UNUSED__, void *surface, void *context)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
Render_Engine *re;
Render_Engine_GL_Surface *sfc;
Render_Engine_GL_Context *ctx;
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
int ret = 0;
declare the variables at the beginning of the block SVN revision: 64516
2011-10-29 22:02:05 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
Render_Engine_GL_Resource *rsc;
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
re = (Render_Engine *)data;
sfc = (Render_Engine_GL_Surface*)surface;
ctx = (Render_Engine_GL_Context*)context;
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Check if direct rendering is possible:
// It's possible when direct_fb_opt is on and either current image
// object is valid or gl_direct_override is on. Override allows
// rendering outside of pixel getter but it doesn't guarantee
// correct rendering.
if ((sfc->direct_fb_opt) && (gl_direct_img_obj || gl_direct_override))
gl_direct_enabled = 1;
else
gl_direct_enabled = 0;
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
// Unset surface/context
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
if ((!sfc) || (!ctx))
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE,
EGL_NO_SURFACE, EGL_NO_CONTEXT);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
ret = glXMakeCurrent(re->info->info.display, None, NULL);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#endif
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
if (!ret)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
ERR("xxxMakeCurrent() failed!");
return 0;
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
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
2011-10-18 01:13:23 -07:00
if (ctx) ctx->current_sfc = NULL;
if (sfc) sfc->current_ctx = NULL;
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
current_evgl_ctx = NULL;
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
2011-10-18 01:13:23 -07:00
return 1;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if (gl_direct_enabled)
{
// Do a make current only if it's not already current
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if ((eglGetCurrentContext() != ctx->context) ||
(eglGetCurrentSurface(EGL_READ) != sfc->direct_sfc) ||
(eglGetCurrentSurface(EGL_DRAW) != sfc->direct_sfc) )
{
int curr_fbo = 0;
DBG("Rendering Directly to the window\n");
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Flush remainder of what's in Evas' pipeline
if (re->win) eng_window_use(NULL);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Do a make current
ret = eglMakeCurrent(re->win->egl_disp, sfc->direct_sfc,
sfc->direct_sfc, ctx->context);
if (!ret)
{
ERR("xxxMakeCurrent() failed! code=%#x", eglGetError());
//ERR("xxxMakeCurrent() failed!");
return 0;
}
glGetIntegerv(GL_FRAMEBUFFER_BINDING, &curr_fbo);
if (ctx->context_fbo == curr_fbo)
{
ctx->current_fbo = 0;
glBindFramebuffer(GL_FRAMEBUFFER, 0);
}
}
#else
if ((glXGetCurrentContext() != ctx->context))
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
2011-10-18 01:13:23 -07:00
{
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Flush remainder of what's in Evas' pipeline
if (re->win) eng_window_use(NULL);
// Do a make current
ret = glXMakeCurrent(re->info->info.display, sfc->direct_sfc, ctx->context);
if (!ret)
{
ERR("xxxMakeCurrent() failed!");
return 0;
}
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
2011-10-18 01:13:23 -07:00
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
else
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
{
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Do a make current only if it's not already current
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
if ((rsc = eina_tls_get(resource_key)) == EINA_FALSE) return 0;
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
2011-10-18 01:13:23 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if ((eglGetCurrentContext() != ctx->context) ||
(eglGetCurrentSurface(EGL_READ) != rsc->surface) ||
(eglGetCurrentSurface(EGL_DRAW) != rsc->surface) )
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
2011-10-18 01:13:23 -07:00
{
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Flush remainder of what's in Evas' pipeline
if (re->win) eng_window_use(NULL);
// Do a make current
ret = eglMakeCurrent(re->win->egl_disp, rsc->surface,
rsc->surface, ctx->context);
if (!ret)
{
ERR("xxxMakeCurrent() failed!");
return 0;
}
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
2011-10-18 01:13:23 -07:00
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
#else
if ((glXGetCurrentContext() != ctx->context) ||
(glXGetCurrentDrawable() != re->win->win) )
{
// Flush remainder of what's in Evas' pipeline
if (re->win) eng_window_use(NULL);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Do a make current
ret = glXMakeCurrent(re->info->info.display, re->win->win, ctx->context);
if (!ret)
{
ERR("xxxMakeCurrent() failed!");
return 0;
}
}
#endif
fixed issues on evas gl suport from sungwoo. SVN revision: 59492
2011-05-18 02:49:58 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Create FBO if not already created
if (!ctx->initialized)
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
{
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
glGenFramebuffers(1, &ctx->context_fbo);
ctx->initialized = 1;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Attach FBO if it hasn't been attached or if surface changed
if ((!sfc->fbo_attached) || (ctx->current_sfc != sfc))
{
if (!_attach_fbo_surface(re, sfc, ctx))
{
ERR("_attach_fbo_surface() failed.");
return 0;
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if (ctx->current_fbo)
// Bind to the previously bound buffer
glBindFramebuffer(GL_FRAMEBUFFER, ctx->current_fbo);
else
// Bind FBO
glBindFramebuffer(GL_FRAMEBUFFER, ctx->context_fbo);
sfc->fbo_attached = 1;
}
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
// Set the current surface/context
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
ctx->current_sfc = sfc;
sfc->current_ctx = ctx;
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
2011-10-18 01:13:23 -07:00
current_evgl_ctx = ctx;
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return 1;
}
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
2011-10-18 01:13:23 -07:00
static void *
warning-- SVN revision: 64387
2011-10-25 05:07:56 -07:00
eng_gl_string_query(void *data __UNUSED__, int name)
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
2011-10-18 01:13:23 -07:00
{
switch(name)
{
case EVAS_GL_EXTENSIONS:
return (void*)_evasgl_ext_string;
default:
return NULL;
};
}
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
static void *
eng_gl_proc_address_get(void *data __UNUSED__, const char *name)
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
if (glsym_eglGetProcAddress) return glsym_eglGetProcAddress(name);
return dlsym(RTLD_DEFAULT, name);
#else
if (glsym_glXGetProcAddress) return glsym_glXGetProcAddress(name);
return dlsym(RTLD_DEFAULT, name);
#endif
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
static int
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
eng_gl_native_surface_get(void *data, void *surface, void *native_surface)
{
Render_Engine *re;
Render_Engine_GL_Surface *sfc;
Evas_Native_Surface *ns;
re = (Render_Engine *)data;
sfc = (Render_Engine_GL_Surface*)surface;
ns = (Evas_Native_Surface*)native_surface;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if (sfc->direct_fb_opt)
{
ns->type = EVAS_NATIVE_SURFACE_OPENGL;
ns->version = EVAS_NATIVE_SURFACE_VERSION;
ns->data.opengl.texture_id = sfc->rt_tex;
ns->data.opengl.framebuffer_id = 0;
ns->data.opengl.x = 0;
ns->data.opengl.y = 0;
ns->data.opengl.w = sfc->w;
ns->data.opengl.h = sfc->h;
}
else
{
ns->type = EVAS_NATIVE_SURFACE_OPENGL;
ns->version = EVAS_NATIVE_SURFACE_VERSION;
ns->data.opengl.texture_id = sfc->rt_tex;
ns->data.opengl.framebuffer_id = sfc->rt_tex;
ns->data.opengl.x = 0;
ns->data.opengl.y = 0;
ns->data.opengl.w = sfc->w;
ns->data.opengl.h = sfc->h;
}
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
return 1;
}
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
2011-10-18 01:13:23 -07:00
static const GLubyte *
evgl_glGetString(GLenum name)
{
if (name == GL_EXTENSIONS)
return (GLubyte *)_gl_ext_string; //glGetString(GL_EXTENSIONS);
else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
return glGetString(name);
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
2011-10-18 01:13:23 -07:00
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
static void
evgl_glBindFramebuffer(GLenum target, GLuint framebuffer)
{
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
Render_Engine_GL_Context *ctx = current_evgl_ctx;
// Take care of BindFramebuffer 0 issue
if (framebuffer==0)
{
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
if (gl_direct_enabled)
glBindFramebuffer(target, 0);
else if (ctx)
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glBindFramebuffer(target, ctx->context_fbo);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
ctx->current_fbo = 0;
}
}
else
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glBindFramebuffer(target, framebuffer);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
// Save this for restore when doing make current
if (ctx)
ctx->current_fbo = framebuffer;
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
}
static void
evgl_glBindRenderbuffer(GLenum target, GLuint renderbuffer)
{
// Add logic to take care when renderbuffer=0
From: "Sung W. Park" <sungwoo@gmail.com> Subject: [E-devel] [Review] [Patch] Evas_GL bug fixes/updates I've fixed some minor issues that I've been pushing off for later. The patch does the following: 1. Evas_GL and Evas had an issue where the viewport parameters were being reset in the wrong context. Previously, this issue was temporarily patched by flushing evas' pipeline and setting evas_gl_common_context_use(NULL) in EvasGL's make current. I know, it was pretty hacky. It turns out that in evas_engine, there was a code evas_gl_common_context_resize(NULL) without doing eng_window_use() first. So i've added that part and problem went was resolved properly. :-) 2. Naturally, I've taken out the temporary patch from 1. 3. I've added code that took care of glBindFramebuffer(..., fbo) where the fbo had to be saved and restored in case the user wanted to use his own fbo. Also, I've had to take care of the case when fbo is 0 since 0 need to point to evas_gl surface. 4. I've updated make_current a little as well. SVN revision: 62780
2011-08-24 23:30:52 -07:00
// On a second thought we don't need this
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glBindRenderbuffer(target, renderbuffer);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// Transform from Evas Coordinat to GL Coordinate
// returns: oc[4] original image object dimension in gl coord
// returns: nc[4] tranformed (x, y, width, heigth) in gl coord
static void
compute_gl_coordinates(Evas_Object *obj, int rot, int clip,
int x, int y, int width, int height,
int imgc[4], int objc[4])
{
int nx1, ny1, nx2, ny2;
int ox1, oy1, ox2, oy2;
if (rot == 0)
{
// oringinal image object coordinate in gl coordinate
imgc[0] = obj->cur.geometry.x;
imgc[1] = obj->layer->evas->output.h - obj->cur.geometry.y - obj->cur.geometry.h;
imgc[2] = imgc[0] + obj->cur.geometry.w;
imgc[3] = imgc[1] + obj->cur.geometry.h;
// transformed (x,y,width,height) in gl coordinate
objc[0] = imgc[0] + x;
objc[1] = imgc[1] + y;
objc[2] = objc[0] + width;
objc[3] = objc[1] + height;
}
else if (rot == 180)
{
// oringinal image object coordinate in gl coordinate
imgc[0] = obj->layer->evas->output.w - obj->cur.geometry.x - obj->cur.geometry.w;
imgc[1] = obj->cur.geometry.y;
imgc[2] = imgc[0] + obj->cur.geometry.w;
imgc[3] = imgc[1] + obj->cur.geometry.h;
// transformed (x,y,width,height) in gl coordinate
objc[0] = imgc[0] + obj->cur.geometry.w - x - width;
objc[1] = imgc[1] + obj->cur.geometry.h - y - height;
objc[2] = objc[0] + width;
objc[3] = objc[1] + height;
}
else if (rot == 90)
{
// oringinal image object coordinate in gl coordinate
imgc[0] = obj->cur.geometry.y;
imgc[1] = obj->cur.geometry.x;
imgc[2] = imgc[0] + obj->cur.geometry.h;
imgc[3] = imgc[1] + obj->cur.geometry.w;
// transformed (x,y,width,height) in gl coordinate
objc[0] = imgc[0] + obj->cur.geometry.h - y - height;
objc[1] = imgc[1] + x;
objc[2] = objc[0] + height;
objc[3] = objc[1] + width;
}
else if (rot == 270)
{
// oringinal image object coordinate in gl coordinate
imgc[0] = obj->layer->evas->output.h - obj->cur.geometry.y - obj->cur.geometry.h;
imgc[1] = obj->layer->evas->output.w - obj->cur.geometry.x - obj->cur.geometry.w;
imgc[2] = imgc[0] + obj->cur.geometry.h;
imgc[3] = imgc[1] + obj->cur.geometry.w;
// transformed (x,y,width,height) in gl coordinate
objc[0] = imgc[0] + y;
objc[1] = imgc[1] + obj->cur.geometry.w - x - width;
objc[2] = objc[0] + height;
objc[3] = objc[1] + width;
}
else
{
ERR("Invalid rotation angle %d.", rot);
return;
}
if (clip)
{
// Clip against original image object
if (objc[0] < imgc[0]) objc[0] = imgc[0];
if (objc[0] > imgc[2]) objc[0] = 0;
if (objc[1] < imgc[1]) objc[1] = imgc[1];
if (objc[1] > imgc[3]) objc[1] = 0;
if (objc[2] < imgc[0]) objc[0] = 0;
if (objc[2] > imgc[2]) objc[2] = imgc[2];
if (objc[3] < imgc[1]) objc[1] = 0;
if (objc[3] > imgc[3]) objc[3] = imgc[3];
}
imgc[2] = imgc[2]-imgc[0]; // width
imgc[3] = imgc[3]-imgc[1]; // height
objc[2] = objc[2]-objc[0]; // width
objc[3] = objc[3]-objc[1]; // height
}
static void
evgl_glClear(GLbitfield mask)
{
Render_Engine_GL_Context *ctx = current_evgl_ctx;
int rot = 0;
int oc[4], nc[4];
if ((gl_direct_img_obj) && (gl_direct_enabled) && (ctx) && (!ctx->current_fbo))
{
if ((current_engine) && (current_engine->win) && (current_engine->win->gl_context))
rot = current_engine->win->gl_context->rot;
else
ERR("Unable to retrieve rotation angle: %d", rot);
compute_gl_coordinates(gl_direct_img_obj, rot, 0, 0, 0, 0, 0, oc, nc);
glScissor(oc[0], oc[1], oc[2], oc[3]);
glClear(mask);
}
else
glClear(mask);
}
static void
evgl_glClearColor(GLclampf red, GLclampf green, GLclampf blue, GLclampf alpha)
{
current_engine->df_clear_color[0] = red;
current_engine->df_clear_color[1] = green;
current_engine->df_clear_color[2] = blue;
current_engine->df_clear_color[3] = alpha;
glClearColor(red, green, blue, alpha);
}
static void
evgl_glEnable(GLenum cap)
{
Render_Engine_GL_Context *ctx = current_evgl_ctx;
if (cap == GL_SCISSOR_TEST)
if (ctx) ctx->scissor_enabled = 1;
glEnable(cap);
}
static void
evgl_glDisable(GLenum cap)
{
Render_Engine_GL_Context *ctx = current_evgl_ctx;
if (cap == GL_SCISSOR_TEST)
if (ctx) ctx->scissor_enabled = 0;
glDisable(cap);
}
static void
evgl_glReadPixels(GLint x, GLint y, GLsizei width, GLsizei height, GLenum format, GLenum type, void* pixels)
{
Render_Engine_GL_Context *ctx = current_evgl_ctx;
int rot = 0;
int oc[4], nc[4];
if ((gl_direct_img_obj) && (gl_direct_enabled) && (ctx) && (!ctx->current_fbo))
{
if ((current_engine) && (current_engine->win) && (current_engine->win->gl_context))
rot = current_engine->win->gl_context->rot;
else
ERR("Unable to retrieve rotation angle: %d", rot);
compute_gl_coordinates(gl_direct_img_obj, rot, 1, x, y, width, height, oc, nc);
glReadPixels(nc[0], nc[1], nc[2], nc[3], format, type, pixels);
}
else
glReadPixels(x, y, width, height, format, type, pixels);
}
static void
evgl_glScissor(GLint x, GLint y, GLsizei width, GLsizei height)
{
Render_Engine_GL_Context *ctx = current_evgl_ctx;
int rot = 0;
int oc[4], nc[4];
if ((gl_direct_img_obj) && (gl_direct_enabled) && (ctx) && (!ctx->current_fbo))
{
if ((current_engine) && (current_engine->win) && (current_engine->win->gl_context))
rot = current_engine->win->gl_context->rot;
else
ERR("Unable to retrieve rotation angle: %d", rot);
compute_gl_coordinates(gl_direct_img_obj, rot, 1, x, y, width, height, oc, nc);
glScissor(nc[0], nc[1], nc[2], nc[3]);
ctx->scissor_upated = 1;
}
else
glScissor(x, y, width, height);
}
static void
evgl_glViewport(GLint x, GLint y, GLsizei width, GLsizei height)
{
Render_Engine_GL_Context *ctx = current_evgl_ctx;
int rot = 0;
int oc[4], nc[4];
if ((gl_direct_img_obj) && (gl_direct_enabled) && (ctx) && (!ctx->current_fbo))
{
if ((current_engine) && (current_engine->win) && (current_engine->win->gl_context))
rot = current_engine->win->gl_context->rot;
else
ERR("Unable to retrieve rotation angle: %d", rot);
compute_gl_coordinates(gl_direct_img_obj, rot, 0, x, y, width, height, oc, nc);
glEnable(GL_SCISSOR_TEST);
glScissor(oc[0], oc[1], oc[2], oc[3]);
glViewport(nc[0], nc[1], nc[2], nc[3]);
}
else
glViewport(x, y, width, height);
}
//----------------------------------------------//
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
static void
evgl_glClearDepthf(GLclampf depth)
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glClearDepthf(depth);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glClearDepth(depth);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#endif
}
static void
evgl_glDepthRangef(GLclampf zNear, GLclampf zFar)
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glDepthRangef(zNear, zFar);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glDepthRange(zNear, zFar);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#endif
}
static void
evgl_glGetShaderPrecisionFormat(GLenum shadertype, GLenum precisiontype, GLint* range, GLint* precision)
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glGetShaderPrecisionFormat(shadertype, precisiontype, range, precision);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#else
if (range)
{
range[0] = -126; // floor(log2(FLT_MIN))
range[1] = 127; // floor(log2(FLT_MAX))
}
if (precision)
{
precision[0] = 24; // floor(-log2((1.0/16777218.0)));
}
return;
shadertype = precisiontype = 0;
#endif
}
static void
evgl_glReleaseShaderCompiler(void)
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glReleaseShaderCompiler();
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#else
#endif
}
static void
evgl_glShaderBinary(GLsizei n, const GLuint* shaders, GLenum binaryformat, const void* binary, GLsizei length)
{
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glShaderBinary(n, shaders, binaryformat, binary, length);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#else
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// FIXME: need to dlsym/getprocaddress for this
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
return;
n = binaryformat = length = 0;
shaders = binary = 0;
#endif
}
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
2011-10-18 01:13:23 -07:00
//--------------------------------//
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// EGL Extensions
static void *
evgl_evasglCreateImage(int target, void* buffer, int *attrib_list)
{
if (current_engine)
{
return glsym_eglCreateImage(current_engine->win->egl_disp,
EGL_NO_CONTEXT,
target,
buffer,
attrib_list);
}
else
Evas (gl_x11): Fix no return value in function that is supposed to have Something returned. SVN revision: 67063
2012-01-11 02:34:03 -08:00
{
ERR("Invalid Engine... (Can't acccess EGL Display)\n");
return NULL;
}
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
2011-10-18 01:13:23 -07:00
}
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
static void
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
2011-10-18 01:13:23 -07:00
evgl_evasglDestroyImage(EvasGLImage image)
{
if (current_engine)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
glsym_eglDestroyImage(current_engine->win->egl_disp, image);
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
2011-10-18 01:13:23 -07:00
else
ERR("Invalid Engine... (Can't acccess EGL Display)\n");
}
static void
evgl_glEvasGLImageTargetTexture2DOES(GLenum target, EvasGLImage image)
{
glsym_glEGLImageTargetTexture2DOES(target, image);
}
static void
evgl_glEvasGLImageTargetRenderbufferStorageOES(GLenum target, EvasGLImage image)
{
glsym_glEGLImageTargetTexture2DOES(target, image);
}
#else
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#endif
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
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
2011-10-18 01:13:23 -07:00
//--------------------------------//
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
static void *
eng_gl_api_get(void *data)
{
Render_Engine *re;
re = (Render_Engine *)data;
gl_funcs.version = EVAS_GL_API_VERSION;
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
2011-10-18 01:13:23 -07:00
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
#define ORD(f) EVAS_API_OVERRIDE(f, &gl_funcs, )
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
2011-10-18 01:13:23 -07:00
// GLES 2.0
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glActiveTexture);
ORD(glAttachShader);
ORD(glBindAttribLocation);
ORD(glBindBuffer);
ORD(glBindTexture);
ORD(glBlendColor);
ORD(glBlendEquation);
ORD(glBlendEquationSeparate);
ORD(glBlendFunc);
ORD(glBlendFuncSeparate);
ORD(glBufferData);
ORD(glBufferSubData);
ORD(glCheckFramebufferStatus);
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// ORD(glClear);
// ORD(glClearColor);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// ORD(glClearDepthf);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glClearStencil);
ORD(glColorMask);
ORD(glCompileShader);
ORD(glCompressedTexImage2D);
ORD(glCompressedTexSubImage2D);
ORD(glCopyTexImage2D);
ORD(glCopyTexSubImage2D);
ORD(glCreateProgram);
ORD(glCreateShader);
ORD(glCullFace);
ORD(glDeleteBuffers);
ORD(glDeleteFramebuffers);
ORD(glDeleteProgram);
ORD(glDeleteRenderbuffers);
ORD(glDeleteShader);
ORD(glDeleteTextures);
ORD(glDepthFunc);
ORD(glDepthMask);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// ORD(glDepthRangef);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glDetachShader);
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// ORD(glDisable);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glDisableVertexAttribArray);
ORD(glDrawArrays);
ORD(glDrawElements);
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// ORD(glEnable);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glEnableVertexAttribArray);
ORD(glFinish);
ORD(glFlush);
ORD(glFramebufferRenderbuffer);
ORD(glFramebufferTexture2D);
ORD(glFrontFace);
ORD(glGenBuffers);
ORD(glGenerateMipmap);
ORD(glGenFramebuffers);
ORD(glGenRenderbuffers);
ORD(glGenTextures);
ORD(glGetActiveAttrib);
ORD(glGetActiveUniform);
ORD(glGetAttachedShaders);
ORD(glGetAttribLocation);
ORD(glGetBooleanv);
ORD(glGetBufferParameteriv);
ORD(glGetError);
ORD(glGetFloatv);
ORD(glGetFramebufferAttachmentParameteriv);
ORD(glGetIntegerv);
ORD(glGetProgramiv);
ORD(glGetProgramInfoLog);
ORD(glGetRenderbufferParameteriv);
ORD(glGetShaderiv);
ORD(glGetShaderInfoLog);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// ORD(glGetShaderPrecisionFormat);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glGetShaderSource);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// ORD(glGetString);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glGetTexParameterfv);
ORD(glGetTexParameteriv);
ORD(glGetUniformfv);
ORD(glGetUniformiv);
ORD(glGetUniformLocation);
ORD(glGetVertexAttribfv);
ORD(glGetVertexAttribiv);
ORD(glGetVertexAttribPointerv);
ORD(glHint);
ORD(glIsBuffer);
ORD(glIsEnabled);
ORD(glIsFramebuffer);
ORD(glIsProgram);
ORD(glIsRenderbuffer);
ORD(glIsShader);
ORD(glIsTexture);
ORD(glLineWidth);
ORD(glLinkProgram);
ORD(glPixelStorei);
ORD(glPolygonOffset);
ORD(glReadPixels);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// ORD(glReleaseShaderCompiler);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glRenderbufferStorage);
ORD(glSampleCoverage);
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// ORD(glScissor);
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// ORD(glShaderBinary);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glShaderSource);
ORD(glStencilFunc);
ORD(glStencilFuncSeparate);
ORD(glStencilMask);
ORD(glStencilMaskSeparate);
ORD(glStencilOp);
ORD(glStencilOpSeparate);
ORD(glTexImage2D);
ORD(glTexParameterf);
ORD(glTexParameterfv);
ORD(glTexParameteri);
ORD(glTexParameteriv);
ORD(glTexSubImage2D);
ORD(glUniform1f);
ORD(glUniform1fv);
ORD(glUniform1i);
ORD(glUniform1iv);
ORD(glUniform2f);
ORD(glUniform2fv);
ORD(glUniform2i);
ORD(glUniform2iv);
ORD(glUniform3f);
ORD(glUniform3fv);
ORD(glUniform3i);
ORD(glUniform3iv);
ORD(glUniform4f);
ORD(glUniform4fv);
ORD(glUniform4i);
ORD(glUniform4iv);
ORD(glUniformMatrix2fv);
ORD(glUniformMatrix3fv);
ORD(glUniformMatrix4fv);
ORD(glUseProgram);
ORD(glValidateProgram);
ORD(glVertexAttrib1f);
ORD(glVertexAttrib1fv);
ORD(glVertexAttrib2f);
ORD(glVertexAttrib2fv);
ORD(glVertexAttrib3f);
ORD(glVertexAttrib3fv);
ORD(glVertexAttrib4f);
ORD(glVertexAttrib4fv);
ORD(glVertexAttribPointer);
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
// ORD(glViewport);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#undef ORD
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
2011-10-18 01:13:23 -07:00
#define ORD(f) EVAS_API_OVERRIDE(f, &gl_funcs, glsym_)
// Extensions
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
ORD(glGetProgramBinaryOES);
ORD(glProgramBinaryOES);
ORD(glMapBufferOES);
ORD(glUnmapBufferOES);
ORD(glGetBufferPointervOES);
ORD(glTexImage3DOES);
ORD(glTexSubImage3DOES);
ORD(glCopyTexSubImage3DOES);
ORD(glCompressedTexImage3DOES);
ORD(glCompressedTexSubImage3DOES);
ORD(glFramebufferTexture3DOES);
ORD(glGetPerfMonitorGroupsAMD);
ORD(glGetPerfMonitorCountersAMD);
ORD(glGetPerfMonitorGroupStringAMD);
ORD(glGetPerfMonitorCounterStringAMD);
ORD(glGetPerfMonitorCounterInfoAMD);
ORD(glGenPerfMonitorsAMD);
ORD(glDeletePerfMonitorsAMD);
ORD(glSelectPerfMonitorCountersAMD);
ORD(glBeginPerfMonitorAMD);
ORD(glEndPerfMonitorAMD);
ORD(glGetPerfMonitorCounterDataAMD);
ORD(glDiscardFramebufferEXT);
ORD(glMultiDrawArraysEXT);
ORD(glMultiDrawElementsEXT);
ORD(glDeleteFencesNV);
ORD(glGenFencesNV);
ORD(glIsFenceNV);
ORD(glTestFenceNV);
ORD(glGetFenceivNV);
ORD(glFinishFenceNV);
ORD(glSetFenceNV);
ORD(glGetDriverControlsQCOM);
ORD(glGetDriverControlStringQCOM);
ORD(glEnableDriverControlQCOM);
ORD(glDisableDriverControlQCOM);
ORD(glExtGetTexturesQCOM);
ORD(glExtGetBuffersQCOM);
ORD(glExtGetRenderbuffersQCOM);
ORD(glExtGetFramebuffersQCOM);
ORD(glExtGetTexLevelParameterivQCOM);
ORD(glExtTexObjectStateOverrideiQCOM);
ORD(glExtGetTexSubImageQCOM);
ORD(glExtGetBufferPointervQCOM);
ORD(glExtGetShadersQCOM);
ORD(glExtGetProgramsQCOM);
ORD(glExtIsProgramBinaryQCOM);
ORD(glExtGetProgramBinarySourceQCOM);
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
2011-10-18 01:13:23 -07:00
#undef ORD
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
// Override functions wrapped by Evas_GL
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
#define ORD(f) EVAS_API_OVERRIDE(f, &gl_funcs, evgl_)
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
ORD(glBindFramebuffer);
ORD(glBindRenderbuffer);
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
ORD(glClear);
ORD(glClearColor);
ORD(glEnable);
ORD(glDisable);
ORD(glReadPixels);
ORD(glScissor);
ORD(glViewport);
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
2011-10-18 01:13:23 -07:00
// GLES2.0 API compat on top of desktop gl
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(glClearDepthf);
ORD(glDepthRangef);
ORD(glGetShaderPrecisionFormat);
ORD(glReleaseShaderCompiler);
ORD(glShaderBinary);
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
2011-10-18 01:13:23 -07:00
ORD(glGetString);
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
// GLES 2.0 Extensions that needs wrapping
ORD(evasglCreateImage);
ORD(evasglDestroyImage);
ORD(glEvasGLImageTargetTexture2DOES);
ORD(glEvasGLImageTargetRenderbufferStorageOES);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
#endif
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
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
2011-10-18 01:13:23 -07:00
#undef ORD
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
return &gl_funcs;
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
static void
eng_gl_img_obj_set(void *data, void *image, int has_alpha)
{
Render_Engine *re = (Render_Engine *)data;
gl_direct_img_obj = NULL;
// Normally direct rendering isn't allowed if alpha is on and
// rotation is not 0. BUT, if override is on, allow it.
if ((has_alpha) && (re->win->gl_context->rot!=0))
{
if (gl_direct_override)
gl_direct_img_obj = image;
}
else
gl_direct_img_obj = image;
}
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
static int
eng_image_load_error_get(void *data __UNUSED__, void *image)
{
Evas_GL_Image *im;
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
if (!image) return EVAS_LOAD_ERROR_NONE;
im = image;
return im->im->cache_entry.load_error;
}
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
static Eina_Bool
eng_image_animated_get(void *data __UNUSED__, void *image)
{
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
Evas_GL_Image *gim = image;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
Image_Entry *im;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
if (!gim) return EINA_FALSE;
im = (Image_Entry *)gim->im;
if (!im) return EINA_FALSE;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
return im->flags.animated;
}
static int
eng_image_animated_frame_count_get(void *data __UNUSED__, void *image)
{
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
Evas_GL_Image *gim = image;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
Image_Entry *im;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
if (!gim) return -1;
im = (Image_Entry *)gim->im;
if (!im) return -1;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
if (!im->flags.animated) return -1;
return im->frame_count;
}
static Evas_Image_Animated_Loop_Hint
eng_image_animated_loop_type_get(void *data __UNUSED__, void *image)
{
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
Evas_GL_Image *gim = image;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
Image_Entry *im;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
if (!gim) return EVAS_IMAGE_ANIMATED_HINT_NONE;
im = (Image_Entry *)gim->im;
if (!im) return EVAS_IMAGE_ANIMATED_HINT_NONE;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
if (!im->flags.animated) return EVAS_IMAGE_ANIMATED_HINT_NONE;
return im->loop_hint;
}
static int
eng_image_animated_loop_count_get(void *data __UNUSED__, void *image)
{
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
Evas_GL_Image *gim = image;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
Image_Entry *im;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
if (!gim) return -1;
im = (Image_Entry *)gim->im;
if (!im) return -1;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
if (!im->flags.animated) return -1;
return im->loop_count;
}
static double
eng_image_animated_frame_duration_get(void *data __UNUSED__, void *image, int start_frame, int frame_num)
{
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
Evas_GL_Image *gim = image;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
Image_Entry *im;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
if (!gim) return -1;
im = (Image_Entry *)gim->im;
if (!im) return -1;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
if (!im->flags.animated) return -1;
return evas_common_load_rgba_image_frame_duration_from_file(im, start_frame, frame_num);
}
static Eina_Bool
eng_image_animated_frame_set(void *data __UNUSED__, void *image, int frame_index)
{
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
Evas_GL_Image *gim = image;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
Image_Entry *im;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: [E-devel] [Patch] modify gl engine's animated function related with cache entry I modified the gl engine code related with animated images This is very trivial. Evas image object passes images to the engine. In the software engine, it is a cache entry , but in the GL engine, it is an Evas_GL Image. So I modified the gl engine code to get the cache entry from the gl image. SVN revision: 64143
2011-10-18 02:10:26 -07:00
if (!gim) return EINA_FALSE;
im = (Image_Entry *)gim->im;
if (!im) return EINA_FALSE;
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
if (!im->flags.animated) return EINA_FALSE;
if (im->cur_frame == frame_index) return EINA_FALSE;
im->cur_frame = frame_index;
return EINA_TRUE;
}
evas: Add api to know if an evas_object_image could support region SVN revision: 66170
2011-12-13 08:58:20 -08:00
static Eina_Bool
Evas: Gl_X11: Fix typo? for __UNUSED__ param. SVN revision: 66224
2011-12-14 10:52:42 -08:00
eng_image_can_region_get(void *data __UNUSED__, void *image)
evas: Add api to know if an evas_object_image could support region SVN revision: 66170
2011-12-13 08:58:20 -08:00
{
Evas_GL_Image *gim = image;
Image_Entry *im;
if (!gim) return EINA_FALSE;
im = (Image_Entry *)gim->im;
if (!im) return EINA_FALSE;
return ((Evas_Image_Load_Func*) im->info.loader)->do_region;
}
add call to get maximum image size (eg max texture size) SVN revision: 64244
2011-10-21 01:17:14 -07:00
static void
eng_image_max_size_get(void *data, int *maxw, int *maxh)
{
Render_Engine *re = (Render_Engine *)data;
if (maxw) *maxw = re->win->gl_context->shared->info.max_texture_size;
if (maxh) *maxh = re->win->gl_context->shared->info.max_texture_size;
}
* evas: Move to Eina module and make it possible to build a libevas with everything in it. Note: This patch break the module API, so make sure you recompile and install every thing. SVN revision: 41055
2009-06-16 06:01:36 -07:00
static int
Exported module functions must be EAPI SVN revision: 25524
2006-09-06 00:28:46 -07:00
module_open(Evas_Module *em)
initial import fo loadable engine modules for evas - from jorge zappie :) SVN revision: 19775
2006-01-14 04:13:38 -08:00
{
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
static Eina_Bool xrm_inited = EINA_FALSE;
if (!xrm_inited)
{
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
xrm_inited = EINA_TRUE;
XrmInitialize();
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
}
initial import fo loadable engine modules for evas - from jorge zappie :) SVN revision: 19775
2006-01-14 04:13:38 -08:00
if (!em) return 0;
better logging. * log domains in lower-case only please. let's make it a standard so we don't have to look at the code everytime to figure out the name... * logs do NOT require trailing newline (\n), it's automatic! * do NOT add newline inside log messages! * add gl_common logging. NOTE: I tried to compile all modules, but there are clear broken modules such as cairo and qtopia. Other modules like gl_sdl are broken as they were not updated to new gl_common api (resize method AFAIR). SVN revision: 53174
2010-10-07 16:46:42 -07:00
if (!evas_gl_common_module_open()) return 0;
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
/* get whatever engine module we inherit from */
if (!_evas_module_engine_inherit(&pfunc, "software_generic")) return 0;
fix some valgrind issues SVN revision: 43657
2009-11-13 00:28:47 -08:00
if (_evas_engine_GL_X11_log_dom < 0)
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
_evas_engine_GL_X11_log_dom = eina_log_domain_register
("evas-gl_x11", EVAS_DEFAULT_LOG_COLOR);
fix some valgrind issues SVN revision: 43657
2009-11-13 00:28:47 -08:00
if (_evas_engine_GL_X11_log_dom < 0)
* evas: Cleanup move to eina log. Patch from Mathieu Taillefumier. SVN revision: 43200
2009-10-22 08:22:22 -07:00
{
better logging. * log domains in lower-case only please. let's make it a standard so we don't have to look at the code everytime to figure out the name... * logs do NOT require trailing newline (\n), it's automatic! * do NOT add newline inside log messages! * add gl_common logging. NOTE: I tried to compile all modules, but there are clear broken modules such as cairo and qtopia. Other modules like gl_sdl are broken as they were not updated to new gl_common api (resize method AFAIR). SVN revision: 53174
2010-10-07 16:46:42 -07:00
EINA_LOG_ERR("Can not create a module log domain.");
fix some valgrind issues SVN revision: 43657
2009-11-13 00:28:47 -08:00
return 0;
* evas: Cleanup move to eina log. Patch from Mathieu Taillefumier. SVN revision: 43200
2009-10-22 08:22:22 -07:00
}
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
/* Allow alpha for evas gl direct rendering */
if (getenv("EVAS_GL_DIRECT_OVERRIDE")) gl_direct_override = 1;
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
/* store it for later use */
func = pfunc;
/* now to override methods */
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
#define ORD(f) EVAS_API_OVERRIDE(f, &func, eng_)
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(info);
ORD(info_free);
ORD(setup);
* evas: gl_x11 window can't support alpha, as drawing rect with alpha=0 is not possible. SVN revision: 41769
2009-08-14 10:11:08 -07:00
ORD(canvas_alpha_get);
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(output_free);
ORD(output_resize);
ORD(output_tile_size_set);
ORD(output_redraws_rect_add);
ORD(output_redraws_rect_del);
ORD(output_redraws_clear);
ORD(output_redraws_next_update_get);
ORD(output_redraws_next_update_push);
ORD(context_cutout_add);
ORD(context_cutout_clear);
ORD(output_flush);
add an engine idle flush SVN revision: 30355
2007-06-16 19:56:59 -07:00
ORD(output_idle_flush);
add ability to dump engine coontents (if engine supports it). this means unload images it has loaded from disk, unload fonts, and more. dump dump dump! SVN revision: 47947
2010-04-12 01:23:53 -07:00
ORD(output_dump);
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(rectangle_draw);
ORD(line_draw);
ORD(polygon_point_add);
ORD(polygon_points_clear);
ORD(polygon_draw);
jose has some new gradient work - these are his patches. nice work joseg! yes - some enignes break as they dont have the stubbed out functions, and xrender/gl engines dont even implement the drawing and need to (but are stubbed out). SVN revision: 35677
2008-08-25 22:45:04 -07:00
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(image_load);
ORD(image_new_from_data);
ORD(image_new_from_copied_data);
ORD(image_free);
ORD(image_size_get);
ORD(image_size_set);
ORD(image_dirty_region);
ORD(image_data_get);
ORD(image_data_put);
Add image preloading support. This should work without performance impact for all engine. SVN revision: 36018
2008-09-16 07:52:57 -07:00
ORD(image_data_preload_request);
ORD(image_data_preload_cancel);
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(image_alpha_set);
ORD(image_alpha_get);
hmmm after some talking - for now put the transform patch on hold - we need tyo fix up some of these breaks first and there isn't a lot of time devoted to this. so revert this. it's in svn history so we can dig it out any time we like. SVN revision: 37453
2008-11-04 01:19:35 -08:00
ORD(image_border_set);
ORD(image_border_get);
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(image_draw);
ORD(image_comment_get);
ORD(image_format_get);
ORD(image_colorspace_set);
ORD(image_colorspace_get);
evas: forget to overide this in gl, fix evas_object_image_region_support_get SVN revision: 66480
2011-12-23 04:00:52 -08:00
ORD(image_can_region_get);
Masking: Push a bit more arbitrary clipping This seems to have got lost in my big messup before. This pushes enough of mask/arbitrary clip to be somewhat useful. I need to push a little more soon for it to be 100% happy, but this is useful level. SVN revision: 58373
2011-04-05 22:38:38 -07:00
ORD(image_mask_create);
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(image_native_set);
ORD(image_native_get);
disable evas filter code. buggy. doesn't work right. SVN revision: 59898
2011-06-02 03:40:43 -07:00
#if 0 // filtering disabled
Evas: Filters: More work, proudly supported by Samsung. Filters! So now you can apply a whole host of cheesy visual effects to objects at runtime. This is the first commit, there are a couple of more to come as I tweak the filters, and fix blur with GL[1]. Please direct bugs to me nash@nash.id.au. [1] You'd think shaders would be good at this.. but no, generic blur and GL are like trying to get an apple product to work with Linux. SVN revision: 58726
2011-04-18 22:47:56 -07:00
ORD(image_draw_filtered);
ORD(image_filtered_get);
ORD(image_filtered_save);
ORD(image_filtered_free);
disable evas filter code. buggy. doesn't work right. SVN revision: 59898
2011-06-02 03:40:43 -07:00
#endif
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
ORD(font_draw);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
1. scale cache now allows you to hint at the object if its dynamic, static or none (ie default) and the engines actually understand it and use it. 2. fixes to scalecache and cserver too. more toto's done and its now been stress tested by me - and i think cserve is ready to go gold. just enable it with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve (cmd-line options avalable plus cmd-line tol to query settings change on the fly and query statsitics and state) SVN revision: 40536
2009-05-07 06:29:56 -07:00
ORD(image_scale_hint_set);
ORD(image_scale_hint_get);
fix 2 unimplemented bits in dynamic texture stuff. SVN revision: 51378
2010-08-18 20:30:47 -07:00
ORD(image_stride_get);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
Support for Proxy Objects (and others) Proxy objects allow you to use another image as the source of an image. Essentially allowing the same object to be rendered multiple times. One object (the source) is the original, each additional 'copy' is an image with evas_object_image_source_set. This is complete. Also add partially working arbitrary maps, and arbitrary clipping. Unfortunately both have some issues yet to be resolved (waiting on the next feature to get merged together). SVN revision: 56777
2011-02-06 15:52:17 -08:00
ORD(image_map_draw);
better text perf - less geometry data for complex text drawing. simpler yuv with matrix. SVN revision: 43487
2009-11-06 03:32:23 -08:00
ORD(image_map_surface_new);
ORD(image_map_surface_free);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
more glue/infra. glue evas api to engine together. gl engine gets stubs. SVN revision: 51028
2010-08-11 23:11:13 -07:00
ORD(image_content_hint_set);
ORD(image_content_hint_get);
improvement to gl engine wrt. caching. SVN revision: 56801
2011-02-08 03:41:38 -08:00
ORD(image_cache_flush);
ORD(image_cache_set);
ORD(image_cache_get);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
ORD(gl_surface_create);
ORD(gl_surface_destroy);
ORD(gl_context_create);
ORD(gl_context_destroy);
ORD(gl_make_current);
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
2011-10-18 01:13:23 -07:00
ORD(gl_string_query);
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
ORD(gl_proc_address_get);
ORD(gl_native_surface_get);
From: "Sung W. Park" <sungwoo@gmail.com> Subject: evas_gl_api_get patch. Here's a patch that simply overrides the GL functions for Evas_GL except for two functions that I provide on my own. It may have some symbol resolving warnings but that'll all go away eventually when we do everything via dlsym or getProcAddress. You can apply the patch to the latest revision of evas. (I've just updated them) I'm also attaching a sample GLES program that uses evas_gl_api_get. You don't need to link it to -lGL. SVN revision: 59092
2011-05-01 19:14:00 -07:00
ORD(gl_api_get);
Added Direct Rendering to Evas' window instead of an FBO in Evas_GL. This optimization is significant for rendering to a large surface because it'l save an extra copy overhead as well as an extra rendering pass. To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface config options_bits. The following conditions have to be met in order for evas to render directly into the Evas' window. If they are not met, the engine will fallback to rendering to an FBO as it normally does. conditions: 1.) All the GL calls have to be called using the pixel_get_callback function. This is necessary for the evas object order to be maintained. 2.) Alpha must be disabled on the image ojbect that renders evas_gl. 3.) No rotation allowed. One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but there is no guarantee in its behavior. Currently, this optimization is added for gl_x11 engine only. SVN revision: 67388
2012-01-20 04:29:14 -08:00
ORD(gl_img_obj_set);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
fix load of data to ACTUALLY set the load error in evas's image objects. including preload. SVN revision: 59529
2011-05-19 04:19:22 -07:00
ORD(image_load_error_get);
whitespaces-------- SVN revision: 60426
2011-06-17 00:47:28 -07:00
From: Jiyoun Park <jy0703.park@samsung.com> Subject: RE: [E-devel] [Patch] Animation gif feature patch Animated gif suport in evas and api's to handle animated images and frame flipping. from jy. SVN revision: 62331
2011-08-10 23:04:08 -07:00
/* now advertise out own api */
ORD(image_animated_get);
ORD(image_animated_frame_count_get);
ORD(image_animated_loop_type_get);
ORD(image_animated_loop_count_get);
ORD(image_animated_frame_duration_get);
ORD(image_animated_frame_set);
add call to get maximum image size (eg max texture size) SVN revision: 64244
2011-10-21 01:17:14 -07:00
ORD(image_max_size_get);
remove white space and tab SVN revision: 65009
2011-11-10 00:59:09 -08:00
1. add new api calls to 1. set a "native surface" for image objects. this currently does nothing and i have kept it VEEERY generic it's a pointer to a native surface which can be just about anything - each engine will probably define a format of its own you need to use VIA the native surface type. 2. add calls to set/get colorspace - moving this down into the engine level. so far engines do nothing at all with it - but api is there. 3. clean up gl engine a bit - make it more standard. SVN revision: 27389
2006-12-09 00:52:08 -08:00
/* now advertise out own api */
em->functions = (void *)(&func);
initial import fo loadable engine modules for evas - from jorge zappie :) SVN revision: 19775
2006-01-14 04:13:38 -08:00
return 1;
}
* evas: Move to Eina module and make it possible to build a libevas with everything in it. Note: This patch break the module API, so make sure you recompile and install every thing. SVN revision: 41055
2009-06-16 06:01:36 -07:00
static void
cleanup: fix some "unused" errors from -Wextra. As we're heading for a release we better remove as much errors as possible and as the first step I'm removing warnings due unused parameters, variables and functions. These tend to pollute real errors spotted by -Wall and clang/llvm. This does not fixes all, just the clear that could be set to __UNUSED__, particularly to do (and I'd like some help from the authors): * src/lib/engines/common/evas_font_{draw,query}.c (tasn): intl_props is just used while doing BIDI, but also used in other #ifdef blocks :-/ * evas_map_* (raster): huge amount of warnings, code is quite confusing and thus I'm not touching it. I have no idea whenever the commented blocks or extra parameters are intended to be used or no. * src/modules/engines/fbevas_fb_main.c (raster?): is fb_setvt() to be used? If not do you mind removing it? * src/modules/engines/gl_{common,x11} (raster): huge amount of warnings, code is quite nested and full of #ifdefs that does not help to give a clear picture of what's going on. * src/bin/evas_cserve_main.c (raster): I could have ignored most of the errors, but is the code correct? I mean, there is no unload of images being applied. If you confirm none of those warnings are harmful I can flag them as unused. * src/lib/engines/common_8 (dottedmag): lots of unused functions that were acquired from common_16, they are unused and if they will not, then they should be removed. SVN revision: 52421
2010-09-18 12:17:41 -07:00
module_close(Evas_Module *em __UNUSED__)
initial import fo loadable engine modules for evas - from jorge zappie :) SVN revision: 19775
2006-01-14 04:13:38 -08:00
{
* evas: Cleanup move to eina log. Patch from Mathieu Taillefumier. SVN revision: 43200
2009-10-22 08:22:22 -07:00
eina_log_domain_unregister(_evas_engine_GL_X11_log_dom);
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
/*
load ~/.Xdefaults less often, make it shared and free its resources. SVN revision: 48420
2010-04-29 08:32:47 -07:00
if (xrdb_user.db)
{
XrmDestroyDatabase(xrdb_user.db);
xrdb_user.last_stat = 0;
xrdb_user.last_mtime = 0;
xrdb_user.db = NULL;
}
disable getting of xft.dpi - always been an option but it just leads to inconsistent rendering. SVN revision: 64386
2011-10-25 05:01:44 -07:00
*/
better logging. * log domains in lower-case only please. let's make it a standard so we don't have to look at the code everytime to figure out the name... * logs do NOT require trailing newline (\n), it's automatic! * do NOT add newline inside log messages! * add gl_common logging. NOTE: I tried to compile all modules, but there are clear broken modules such as cairo and qtopia. Other modules like gl_sdl are broken as they were not updated to new gl_common api (resize method AFAIR). SVN revision: 53174
2010-10-07 16:46:42 -07:00
evas_gl_common_module_close();
initial import fo loadable engine modules for evas - from jorge zappie :) SVN revision: 19775
2006-01-14 04:13:38 -08:00
}
* evas: Move to Eina module and make it possible to build a libevas with everything in it. Note: This patch break the module API, so make sure you recompile and install every thing. SVN revision: 41055
2009-06-16 06:01:36 -07:00
static Evas_Module_Api evas_modapi =
initial import fo loadable engine modules for evas - from jorge zappie :) SVN revision: 19775
2006-01-14 04:13:38 -08:00
{
EVAS_MODULE_API_VERSION,
* evas: Move to Eina module and make it possible to build a libevas with everything in it. Note: This patch break the module API, so make sure you recompile and install every thing. SVN revision: 41055
2009-06-16 06:01:36 -07:00
"gl_x11",
"none",
{
sorry sungwoo - going to have to back this dlopen/dlsym styuff out. intel drivers don;'t like it for some odd reason - i'm trying to track it down but i can't sanely try middlegrounds right now (eg dont dlopen/dlsym but actually directly assign symbols etc.), so back out and let's figure this out before it goes back in :( SVN revision: 66308
2011-12-17 21:03:24 -08:00
module_open,
module_close
* evas: Move to Eina module and make it possible to build a libevas with everything in it. Note: This patch break the module API, so make sure you recompile and install every thing. SVN revision: 41055
2009-06-16 06:01:36 -07:00
}
initial import fo loadable engine modules for evas - from jorge zappie :) SVN revision: 19775
2006-01-14 04:13:38 -08:00
};
* evas: Move to Eina module and make it possible to build a libevas with everything in it. Note: This patch break the module API, so make sure you recompile and install every thing. SVN revision: 41055
2009-06-16 06:01:36 -07:00
EVAS_MODULE_DEFINE(EVAS_MODULE_TYPE_ENGINE, engine, gl_x11);
Fix building gl_xlib as a static module SVN revision: 61164
2011-07-08 18:47:01 -07:00
#ifndef EVAS_STATIC_BUILD_GL_XLIB
* evas: Move to Eina module and make it possible to build a libevas with everything in it. Note: This patch break the module API, so make sure you recompile and install every thing. SVN revision: 41055
2009-06-16 06:01:36 -07:00
EVAS_EINA_MODULE_DEFINE(engine, gl_x11);
#endif
API add: From <dunamis.park@samsung.com> - sungwoo start of evas gl api (with compile warning fixes). SVN revision: 58318
2011-04-04 03:23:12 -07:00
/* vim:set ts=8 sw=3 sts=3 expandtab cino=>5n-2f0^-2{2(0W1st0 :*/