2010-07-28 05:00:41 -07:00
|
|
|
#include "evas_common.h" /* Also includes international specific stuff */
|
2009-10-09 05:10:27 -07:00
|
|
|
#include "evas_engine.h"
|
|
|
|
|
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
|
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
#define EVAS_GL_NO_GL_H_CHECK 1
|
|
|
|
#include "Evas_GL.h"
|
2010-01-21 00:44:11 -08:00
|
|
|
|
2009-10-09 05:10:27 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-01-21 00:44:11 -08:00
|
|
|
// EGL / GLES
|
2009-10-09 05:10:27 -07:00
|
|
|
# if defined(GLES_VARIETY_S3C6410)
|
|
|
|
# elif defined(GLES_VARIETY_SGX)
|
|
|
|
# endif
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
2009-10-09 05:10:27 -07:00
|
|
|
// GLX
|
2010-01-21 00:44:11 -08:00
|
|
|
#endif
|
|
|
|
|
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;
|
2010-08-02 23:09:53 -07:00
|
|
|
|
|
|
|
struct _Render_Engine
|
|
|
|
{
|
|
|
|
Evas_GL_X11_Window *win;
|
|
|
|
Evas_Engine_Info_GL_X11 *info;
|
|
|
|
Evas *evas;
|
2011-10-21 01:58:00 -07:00
|
|
|
Tilebuf *tb;
|
2010-08-02 23:09:53 -07:00
|
|
|
int end;
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
2010-08-02 23:09:53 -07:00
|
|
|
XrmDatabase xrdb; // xres - dpi
|
|
|
|
struct { // xres - dpi
|
|
|
|
int dpi; // xres - dpi
|
|
|
|
} xr; // xres - dpi
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2010-08-26 02:40:48 -07:00
|
|
|
int w, h;
|
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
|
|
|
|
2010-08-02 23:09:53 -07:00
|
|
|
};
|
|
|
|
|
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;
|
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;
|
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;
|
2011-06-17 00:47:28 -07:00
|
|
|
#else
|
2011-04-04 03:23:12 -07:00
|
|
|
GLXContext context;
|
|
|
|
#endif
|
2011-11-10 00:59:09 -08:00
|
|
|
GLuint context_fbo;
|
2011-08-24 23:30:52 -07:00
|
|
|
GLuint current_fbo;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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
|
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;
|
|
|
|
};
|
|
|
|
|
2010-08-02 23:09:53 -07:00
|
|
|
static int initted = 0;
|
|
|
|
static int gl_wins = 0;
|
2011-08-24 23:30:52 -07:00
|
|
|
static Render_Engine_GL_Context *current_evgl_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
|
|
|
static Render_Engine *current_engine;
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
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) ();
|
2011-12-17 21:03:24 -08:00
|
|
|
typedef unsigned char *(*glsym_func_uchar_ptr) ();
|
|
|
|
typedef const char *(*glsym_func_const_char_ptr) ();
|
2010-08-02 23:09:53 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-01-28 21:32:51 -08:00
|
|
|
|
|
|
|
#ifndef EGL_NATIVE_PIXMAP_KHR
|
|
|
|
# define EGL_NATIVE_PIXMAP_KHR 0x30b0
|
|
|
|
#endif
|
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;
|
2010-01-21 00:44:11 -08:00
|
|
|
|
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;
|
2010-01-21 00:44:11 -08:00
|
|
|
#endif
|
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;
|
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)
|
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 },
|
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 },
|
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 },
|
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 },
|
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 },
|
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 },
|
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 },
|
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 ???
|
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 }
|
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
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
static void
|
|
|
|
_sym_init(void)
|
|
|
|
{
|
|
|
|
static int done = 0;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
if (done) return;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
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)
|
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);
|
|
|
|
|
2008-04-11 17:32:30 -07:00
|
|
|
#else
|
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)
|
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
|
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(" ");
|
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
|
|
|
|
evasglexts = glsym_eglQueryString(re->win->egl_disp, EGL_EXTENSIONS);
|
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
evasglexts = glXQueryExtensionsString(re->info->info.display,
|
|
|
|
re->info->info.screen);
|
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
|
|
|
|
|
|
|
DBG("--------EvasGL Extensions----------");
|
|
|
|
for (i = 0; _evasgl_ext_entries[i].name != NULL; i++)
|
|
|
|
{
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
DBG(" ");
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
2008-04-11 17:32:30 -07:00
|
|
|
|
2009-10-22 08:22:22 -07:00
|
|
|
int _evas_engine_GL_X11_log_dom = -1;
|
2006-12-09 00:52:08 -08:00
|
|
|
/* function tables - filled in later (func and parent func) */
|
|
|
|
static Evas_Func func, pfunc;
|
2006-02-27 20:07:49 -08:00
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
/* Function table for GL APIs */
|
|
|
|
static Evas_GL_API gl_funcs;
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
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;
|
2011-10-25 05:01:44 -07:00
|
|
|
if (last != now) // don't stat() more than once every second
|
2010-04-29 08:32:47 -07:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
struct stat st;
|
|
|
|
const char *home = getenv("HOME");
|
|
|
|
char tmp[PATH_MAX];
|
2010-04-29 08:32:47 -07:00
|
|
|
|
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;
|
|
|
|
}
|
2010-04-29 08:32:47 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!xrdb_user.db) return EINA_FALSE;
|
|
|
|
return XrmGetResource(xrdb_user.db, name, cls, type, val);
|
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
failed:
|
2010-04-29 08:32:47 -07:00
|
|
|
if (xrdb_user.db)
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
XrmDestroyDatabase(xrdb_user.db);
|
|
|
|
xrdb_user.db = NULL;
|
2010-04-29 08:32:47 -07:00
|
|
|
}
|
|
|
|
xrdb_user.last_mtime = 0;
|
|
|
|
return EINA_FALSE;
|
|
|
|
}
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void *
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_info(Evas *e)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Evas_Engine_Info_GL_X11 *info;
|
2010-01-21 00:44:11 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
info = calloc(1, sizeof(Evas_Engine_Info_GL_X11));
|
|
|
|
info->magic.magic = rand();
|
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;
|
2010-05-21 00:10:45 -07:00
|
|
|
info->render_mode = EVAS_RENDER_MODE_BLOCKING;
|
2002-11-08 00:02:15 -08:00
|
|
|
return info;
|
|
|
|
e = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_info_free(Evas *e __UNUSED__, void *info)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Evas_Engine_Info_GL_X11 *in;
|
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);
|
2002-11-08 00:02:15 -08:00
|
|
|
in = (Evas_Engine_Info_GL_X11 *)info;
|
|
|
|
free(in);
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
2010-10-07 16:46:42 -07:00
|
|
|
ERR("GL engine can't re-create window surface!");
|
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
|
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
|
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)
|
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
|
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)
|
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)
|
|
|
|
{
|
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)
|
|
|
|
{
|
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
|
|
|
{
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-24 02:05:32 -07:00
|
|
|
static int
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_setup(Evas *e, void *in)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Evas_Engine_Info_GL_X11 *info;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
info = (Evas_Engine_Info_GL_X11 *)in;
|
|
|
|
if (!e->engine.data.output)
|
2006-12-09 00:52:08 -08:00
|
|
|
{
|
2009-10-09 05:10:27 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-06-17 00:47:28 -07:00
|
|
|
#else
|
2010-01-21 21:55:46 -08:00
|
|
|
int eb, evb;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
if (!glXQueryExtension(info->info.display, &eb, &evb)) return 0;
|
2009-10-09 05:10:27 -07:00
|
|
|
#endif
|
2011-11-10 00:59:09 -08:00
|
|
|
re = calloc(1, sizeof(Render_Engine));
|
|
|
|
if (!re) return 0;
|
2010-01-24 03:01:20 -08:00
|
|
|
re->info = info;
|
|
|
|
re->evas = e;
|
2011-11-10 00:59:09 -08:00
|
|
|
e->engine.data.output = re;
|
2010-08-26 02:40:48 -07:00
|
|
|
re->w = e->output.w;
|
|
|
|
re->h = e->output.h;
|
2011-11-10 00:59:09 -08:00
|
|
|
re->win = eng_window_new(re->info->info.display,
|
|
|
|
re->info->info.drawable,
|
2010-08-26 02:40:48 -07:00
|
|
|
re->info->info.screen,
|
2011-11-10 00:59:09 -08:00
|
|
|
re->info->info.visual,
|
|
|
|
re->info->info.colormap,
|
|
|
|
re->info->info.depth,
|
2010-08-26 02:40:48 -07:00
|
|
|
re->w,
|
|
|
|
re->h,
|
|
|
|
re->info->indirect,
|
|
|
|
re->info->info.destination_alpha,
|
|
|
|
re->info->info.rotation);
|
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
|
|
|
}
|
|
|
|
|
2010-05-17 21:22:33 -07:00
|
|
|
gl_wins++;
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
2010-01-07 23:10:53 -08:00
|
|
|
{
|
|
|
|
int status;
|
|
|
|
char *type = NULL;
|
|
|
|
XrmValue val;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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))
|
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
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
if ((status) && (type))
|
|
|
|
{
|
|
|
|
if (!strcmp(type, "String"))
|
|
|
|
{
|
|
|
|
const char *str, *dp;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
str = val.addr;
|
|
|
|
dp = strchr(str, '.');
|
|
|
|
if (!dp) dp = strchr(str, ',');
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
if (dp)
|
|
|
|
{
|
|
|
|
int subdpi, len, i;
|
|
|
|
char *buf;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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
|
2011-12-17 21:03:24 -08:00
|
|
|
re->xr.dpi = atoi(str) * 1000;
|
2010-01-30 18:50:01 -08:00
|
|
|
evas_common_font_dpi_set(re->xr.dpi / 1000);
|
2010-01-07 23:10:53 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2010-05-17 21:22:33 -07:00
|
|
|
if (!initted)
|
|
|
|
{
|
|
|
|
evas_common_cpu_init();
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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);
|
|
|
|
|
2010-05-17 21:22:33 -07:00
|
|
|
initted = 1;
|
|
|
|
}
|
2006-12-09 00:52:08 -08:00
|
|
|
}
|
2006-03-08 00:02:34 -08:00
|
|
|
else
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
re = e->engine.data.output;
|
2010-08-26 02:40:48 -07:00
|
|
|
if (_re_wincheck(re))
|
2010-01-25 06:02:14 -08:00
|
|
|
{
|
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))
|
2010-07-28 01:11:30 -07:00
|
|
|
{
|
2010-08-26 02:40:48 -07:00
|
|
|
int inc = 0;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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);
|
2011-04-06 03:11:01 -07:00
|
|
|
eng_window_use(re->win);
|
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);
|
2010-07-28 01:11:30 -07:00
|
|
|
}
|
2010-01-25 06:02:14 -08:00
|
|
|
}
|
2006-03-08 00:02:34 -08:00
|
|
|
}
|
2010-05-17 20:49:59 -07:00
|
|
|
if (!re->win)
|
|
|
|
{
|
|
|
|
free(re);
|
|
|
|
return 0;
|
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-05-17 20:49:59 -07:00
|
|
|
if (!e->engine.data.output)
|
|
|
|
{
|
2010-05-17 21:22:33 -07:00
|
|
|
if (re->win)
|
|
|
|
{
|
|
|
|
eng_window_free(re->win);
|
|
|
|
gl_wins--;
|
|
|
|
}
|
2010-05-17 20:49:59 -07:00
|
|
|
free(re);
|
|
|
|
return 0;
|
|
|
|
}
|
2011-11-10 00:59:09 -08:00
|
|
|
re->tb = evas_common_tilebuf_new(re->win->w, re->win->h);
|
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);
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
if (!e->engine.data.context)
|
2011-12-17 21:03:24 -08:00
|
|
|
e->engine.data.context =
|
|
|
|
e->engine.func->context_new(e->engine.data.output);
|
2009-10-13 02:40:39 -07:00
|
|
|
eng_window_use(re->win);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
2010-10-25 00:22:43 -07:00
|
|
|
re->vsync = 0;
|
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;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-03-24 02:05:32 -07:00
|
|
|
return 1;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_free(void *data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-05-17 20:49:59 -07:00
|
|
|
if (re)
|
|
|
|
{
|
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);
|
2010-04-29 08:32:47 -07:00
|
|
|
|
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
|
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))
|
2011-12-17 21:03:24 -08:00
|
|
|
_destroy_internal_glue_resources(re);
|
2010-05-17 21:22:33 -07:00
|
|
|
eng_window_free(re->win);
|
|
|
|
gl_wins--;
|
|
|
|
}
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_free(re->tb);
|
2010-05-17 20:49:59 -07:00
|
|
|
free(re);
|
|
|
|
}
|
2010-05-17 21:22:33 -07:00
|
|
|
if ((initted == 1) && (gl_wins == 0))
|
|
|
|
{
|
|
|
|
evas_common_image_shutdown();
|
|
|
|
evas_common_font_shutdown();
|
|
|
|
initted = 0;
|
|
|
|
}
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_resize(void *data, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2003-09-04 00:40:34 -07:00
|
|
|
re->win->w = w;
|
|
|
|
re->win->h = h;
|
2009-10-13 02:40:39 -07:00
|
|
|
eng_window_use(re->win);
|
2010-05-08 22:15:20 -07:00
|
|
|
evas_gl_common_context_resize(re->win->gl_context, w, h, re->win->rot);
|
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);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-10-21 01:58:00 -07:00
|
|
|
eng_output_tile_size_set(void *data, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
2011-10-21 01:58:00 -07:00
|
|
|
Render_Engine *re;
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2011-10-21 01:58:00 -07:00
|
|
|
re = (Render_Engine *)data;
|
|
|
|
evas_common_tilebuf_set_tile_size(re->tb, w, h);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_redraws_rect_add(void *data, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-08-24 23:30:52 -07:00
|
|
|
eng_window_use(re->win);
|
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);
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_add_redraw(re->tb, x, y, w, h);
|
2011-12-31 22:47:16 -08:00
|
|
|
|
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;
|
2003-09-04 00:40:34 -07:00
|
|
|
if (!re->win->draw.redraw)
|
|
|
|
{
|
2011-12-31 22:47:16 -08:00
|
|
|
#if 1
|
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;
|
2004-06-18 08:56:30 -07:00
|
|
|
#else
|
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;
|
2005-05-21 19:49:50 -07:00
|
|
|
#endif
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
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;
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
|
|
|
re->win->draw.redraw = 1;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-12-05 16:44:25 -08:00
|
|
|
eng_output_redraws_rect_del(void *data, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
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);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_redraws_clear(void *data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_clear(re->tb);
|
|
|
|
/* re->win->draw.redraw = 0;*/
|
2011-12-17 21:03:24 -08:00
|
|
|
// INF("GL: finish update cycle!");
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2007-03-03 08:05:15 -08:00
|
|
|
/* vsync games - not for now though */
|
2010-01-29 09:14:50 -08:00
|
|
|
#define VSYNC_TO_SCREEN 1
|
2007-03-03 08:05:15 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void *
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2011-10-21 01:58:00 -07:00
|
|
|
Tilebuf_Rect *rects;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2003-09-04 00:40:34 -07:00
|
|
|
/* get the upate rect surface - return engine data as dummy */
|
2011-10-21 01:58:00 -07:00
|
|
|
rects = evas_common_tilebuf_get_render_rects(re->tb);
|
|
|
|
if (rects)
|
|
|
|
{
|
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);
|
|
|
|
}
|
|
|
|
*/
|
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;
|
|
|
|
/*
|
2010-02-11 06:41:44 -08:00
|
|
|
if (!re->win->draw.redraw) return NULL;
|
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
|
2010-12-02 00:01:19 -08:00
|
|
|
eng_window_use(NULL);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
2010-12-02 00:01:19 -08:00
|
|
|
eng_window_use(re->win);
|
2010-08-26 02:40:48 -07:00
|
|
|
if (!_re_wincheck(re)) return NULL;
|
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);
|
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;
|
2009-11-12 23:22:31 -08:00
|
|
|
return re->win->gl_context->def_surface;
|
2011-10-21 01:58:00 -07:00
|
|
|
*/
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2010-03-31 02:25:21 -07:00
|
|
|
//#define FRAMECOUNT 1
|
|
|
|
|
2012-01-11 01:48:47 -08:00
|
|
|
#ifdef FRAMECOUNT
|
2011-12-31 22:47:16 -08:00
|
|
|
static double
|
2010-03-31 02:25:21 -07:00
|
|
|
get_time(void)
|
|
|
|
{
|
2012-01-11 01:48:47 -08:00
|
|
|
struct timeval timev;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-03-31 02:25:21 -07:00
|
|
|
gettimeofday(&timev, NULL);
|
|
|
|
return (double)timev.tv_sec + (((double)timev.tv_usec) / 1000000);
|
|
|
|
}
|
2012-01-11 01:48:47 -08:00
|
|
|
#endif
|
2010-03-31 02:25:21 -07:00
|
|
|
|
2010-10-25 00:22:43 -07:00
|
|
|
static int safe_native = -1;
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void
|
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__)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
static double pt = 0.0;
|
|
|
|
double ta, tb;
|
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2003-09-04 00:40:34 -07:00
|
|
|
/* put back update surface.. in this case just unflag redraw */
|
2010-08-26 02:40:48 -07:00
|
|
|
if (!_re_wincheck(re)) return;
|
2003-09-04 00:40:34 -07:00
|
|
|
re->win->draw.redraw = 0;
|
2007-03-04 09:06:13 -08:00
|
|
|
re->win->draw.drew = 1;
|
2009-10-09 05:10:27 -07:00
|
|
|
evas_gl_common_context_flush(re->win->gl_context);
|
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);
|
2010-10-24 18:57:48 -07:00
|
|
|
else
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
s = (const char *)glGetString(GL_RENDERER);
|
2010-10-24 18:57:48 -07:00
|
|
|
if (s)
|
|
|
|
{
|
2011-07-10 23:29:20 -07:00
|
|
|
if (strstr(s, "PowerVR SGX 540") ||
|
2011-08-11 20:50:57 -07:00
|
|
|
strstr(s, "Mali-400 MP"))
|
2011-12-17 21:03:24 -08:00
|
|
|
safe_native = 1;
|
2010-10-24 18:57:48 -07:00
|
|
|
}
|
|
|
|
}
|
2010-10-22 01:17:37 -07:00
|
|
|
}
|
2010-02-01 21:30:19 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-02-06 00:38:26 -08:00
|
|
|
// this is needed to make sure all previous rendering is flushed to
|
|
|
|
// buffers/surfaces
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t0 = get_time();
|
|
|
|
ta = t0 - pt;
|
|
|
|
pt = t0;
|
|
|
|
#endif
|
2010-10-22 01:17:37 -07:00
|
|
|
// previous rendering should be done and swapped
|
2011-12-17 21:03:24 -08:00
|
|
|
if (!safe_native) eglWaitNative(EGL_CORE_NATIVE_ENGINE);
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t1 = get_time();
|
|
|
|
tb = t1 - t0;
|
|
|
|
printf("... %1.5f -> %1.5f | ", ta, tb);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
2011-12-17 21:03:24 -08:00
|
|
|
// if (eglGetError() != EGL_SUCCESS)
|
|
|
|
// {
|
|
|
|
// printf("Error: eglWaitNative(EGL_CORE_NATIVE_ENGINE) fail.\n");
|
|
|
|
// }
|
2010-02-01 21:30:19 -08:00
|
|
|
#else
|
2010-10-22 01:17:37 -07:00
|
|
|
// previous rendering should be done and swapped
|
2011-12-17 21:03:24 -08:00
|
|
|
if (!safe_native) glXWaitX();
|
2010-02-01 21:30:19 -08:00
|
|
|
#endif
|
2011-12-17 21:03:24 -08:00
|
|
|
//x// printf("frame -> push\n");
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_flush(void *data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2010-08-26 02:40:48 -07:00
|
|
|
if (!_re_wincheck(re)) return;
|
2007-03-04 09:06:13 -08:00
|
|
|
if (!re->win->draw.drew) return;
|
2011-12-17 21:03:24 -08:00
|
|
|
//x// printf("frame -> flush\n");
|
2007-03-04 09:06:13 -08:00
|
|
|
re->win->draw.drew = 0;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2003-09-04 00:40:34 -07:00
|
|
|
|
2010-01-24 03:01:20 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t0 = get_time();
|
2010-08-01 23:44:23 -07:00
|
|
|
#endif
|
2010-10-25 00:22:43 -07:00
|
|
|
if (!re->vsync)
|
|
|
|
{
|
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);
|
2010-10-25 00:22:43 -07:00
|
|
|
re->vsync = 1;
|
|
|
|
}
|
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);
|
|
|
|
}
|
2011-12-17 21:03:24 -08:00
|
|
|
eglSwapBuffers(re->win->egl_disp, re->win->egl_surface[0]);
|
|
|
|
if (!safe_native) eglWaitGL();
|
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);
|
|
|
|
}
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t1 = get_time();
|
|
|
|
printf("%1.5f\n", t1 - t0);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
2011-12-17 21:03:24 -08:00
|
|
|
// if (eglGetError() != EGL_SUCCESS)
|
|
|
|
// {
|
|
|
|
// printf("Error: eglSwapBuffers() fail.\n");
|
|
|
|
// }
|
2009-10-09 05:10:27 -07:00
|
|
|
#else
|
2011-06-17 00:47:28 -07:00
|
|
|
#ifdef VSYNC_TO_SCREEN
|
2010-02-11 06:41:44 -08:00
|
|
|
if ((re->info->vsync)/* || (1)*/)
|
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)
|
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);
|
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)
|
2010-01-29 09:14:50 -08:00
|
|
|
{
|
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);
|
2010-12-26 02:15:28 -08:00
|
|
|
re->vsync = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if ((glsym_glXGetVideoSync) && (glsym_glXWaitVideoSync))
|
|
|
|
{
|
|
|
|
unsigned int rc;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-12-26 02:15:28 -08:00
|
|
|
glsym_glXGetVideoSync(&rc);
|
|
|
|
glsym_glXWaitVideoSync(1, 0, &rc);
|
|
|
|
}
|
2010-01-29 09:14:50 -08:00
|
|
|
}
|
|
|
|
}
|
2009-10-09 05:10:27 -07:00
|
|
|
# endif
|
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);
|
|
|
|
}
|
2012-01-01 19:32:57 -08:00
|
|
|
#if 1
|
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
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
2011-12-31 22:47:16 -08:00
|
|
|
// double t, t2 = 0.0;
|
|
|
|
// t = get_time();
|
2011-12-17 21:03:24 -08:00
|
|
|
glXSwapBuffers(re->win->disp, re->win->win);
|
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);
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
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;
|
2011-12-31 22:47:16 -08:00
|
|
|
|
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);
|
2011-12-31 22:47:16 -08:00
|
|
|
glDrawBuffer(GL_FRONT);
|
2011-12-17 21:03:24 -08:00
|
|
|
glCopyPixels(sx, sy, sw, sh, GL_COLOR);
|
|
|
|
glDrawBuffer(GL_BACK);
|
2012-01-01 19:30:23 -08:00
|
|
|
glDisable(GL_SCISSOR_TEST);
|
|
|
|
glBitmap(0, 0, 0, 0, 0, 0, NULL);
|
2011-12-17 21:03:24 -08:00
|
|
|
glFlush();
|
|
|
|
}
|
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);
|
|
|
|
}
|
2010-02-28 20:44:23 -08:00
|
|
|
#endif
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2007-06-16 19:56:59 -07:00
|
|
|
static void
|
|
|
|
eng_output_idle_flush(void *data)
|
|
|
|
{
|
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);
|
2010-08-26 02:40:48 -07:00
|
|
|
_re_winfree(re);
|
2007-06-16 19:56:59 -07:00
|
|
|
}
|
|
|
|
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
|
|
|
// re->win->gl_context->dc = context;
|
2009-02-20 19:13:49 -08:00
|
|
|
evas_common_draw_context_add_cutout(context, x, y, w, h);
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
|
|
|
// re->win->gl_context->dc = context;
|
2009-02-20 19:13:49 -08:00
|
|
|
evas_common_draw_context_clear_cutouts(context);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
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);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
2006-09-30 03:18:37 -07:00
|
|
|
re->win->gl_context->dc = context;
|
2009-12-30 03:35:40 -08:00
|
|
|
evas_gl_common_line_draw(re->win->gl_context, x1, y1, x2, y2);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_polygon_point_add(void *data, void *context __UNUSED__, void *polygon, int x, int y)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-12-26 16:40:25 -08:00
|
|
|
return evas_gl_common_poly_point_add(polygon, x, y);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_polygon_points_clear(void *data, void *context __UNUSED__, void *polygon)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-12-26 16:40:25 -08:00
|
|
|
return evas_gl_common_poly_points_clear(polygon);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2010-03-16 06:23:37 -07:00
|
|
|
eng_polygon_draw(void *data, void *context, void *surface __UNUSED__, void *polygon, int x, int y)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
2006-09-30 03:18:37 -07:00
|
|
|
re->win->gl_context->dc = context;
|
2010-03-16 06:23:37 -07:00
|
|
|
evas_gl_common_poly_draw(re->win->gl_context, polygon, x, y);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
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)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
// re = (Render_Engine *)data;
|
2006-12-17 08:46:30 -08:00
|
|
|
if (!image) return 1;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-01-21 04:43:53 -08:00
|
|
|
return im->alpha;
|
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)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
2009-02-21 00:19:58 -08:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
// re = (Render_Engine *)data;
|
2006-12-17 08:46:30 -08:00
|
|
|
if (!image) return EVAS_COLORSPACE_ARGB8888;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
|
|
|
return im->cs.space;
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-08-18 22:18:17 -07:00
|
|
|
if (im->alpha == has_alpha) return image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
im->alpha = has_alpha;
|
|
|
|
return image;
|
|
|
|
}
|
2010-01-21 04:43:53 -08:00
|
|
|
eng_window_use(re->win);
|
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;
|
|
|
|
}
|
2006-12-17 07:48:52 -08:00
|
|
|
/* FIXME: can move to gl_common */
|
|
|
|
if (im->cs.space != EVAS_COLORSPACE_ARGB8888) return im;
|
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;
|
2006-12-17 07:48:52 -08:00
|
|
|
if (im->references > 1)
|
2009-10-09 05:10:27 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *im_new;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-08-25 02:29:56 -07:00
|
|
|
im_new = evas_gl_common_image_new_from_copied_data
|
2011-06-17 00:47:28 -07:00
|
|
|
(im->gc, im->im->cache_entry.w, im->im->cache_entry.h,
|
2011-12-17 21:03:24 -08:00
|
|
|
im->im->image.data,
|
|
|
|
eng_image_alpha_get(data, image),
|
|
|
|
eng_image_colorspace_get(data, image));
|
2009-10-09 05:10:27 -07:00
|
|
|
if (!im_new) return im;
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
im = im_new;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
else
|
2011-12-17 21:03:24 -08:00
|
|
|
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
|
2010-02-21 07:49:44 -08:00
|
|
|
return evas_gl_common_image_alpha_set(im, has_alpha ? 1 : 0);
|
2011-12-17 21:03:24 -08:00
|
|
|
// im->im->cache_entry.flags.alpha = has_alpha ? 1 : 0;
|
|
|
|
// return image;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
|
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__)
|
2008-11-04 01:19:35 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
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__)
|
2008-11-04 01:19:35 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
2008-11-04 01:19:35 -08:00
|
|
|
}
|
|
|
|
|
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__)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
// re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-01-21 04:43:53 -08:00
|
|
|
if (!im->im) return NULL;
|
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)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
// re = (Render_Engine *)data;
|
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;
|
2009-02-21 00:19:58 -08:00
|
|
|
|
2006-12-17 07:48:52 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data) return;
|
2006-12-17 07:48:52 -08:00
|
|
|
/* FIXME: can move to gl_common */
|
|
|
|
if (im->cs.space == cspace) return;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
2008-04-11 17:32:30 -07:00
|
|
|
evas_cache_image_colorspace(&im->im->cache_entry, cspace);
|
2006-12-17 07:48:52 -08:00
|
|
|
switch (cspace)
|
|
|
|
{
|
|
|
|
case EVAS_COLORSPACE_ARGB8888:
|
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;
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_YCBCR422P601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P709_PL:
|
2011-08-23 08:13:40 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR422601_PL:
|
2011-08-29 13:56:48 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
|
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;
|
2006-12-17 07:48:52 -08:00
|
|
|
default:
|
2011-11-10 00:59:09 -08:00
|
|
|
abort();
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
im->cs.space = cspace;
|
|
|
|
}
|
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
//
|
|
|
|
typedef struct _Native Native;
|
|
|
|
|
|
|
|
struct _Native
|
|
|
|
{
|
|
|
|
Evas_Native_Surface ns;
|
|
|
|
Pixmap pixmap;
|
|
|
|
Visual *visual;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-01-28 21:32:51 -08:00
|
|
|
void *egl_surface;
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
2010-02-14 07:12:39 -08:00
|
|
|
void *fbc;
|
|
|
|
XID glx_pixmap;
|
2010-01-21 00:44:11 -08:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
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.
|
2011-06-17 00:47:28 -07:00
|
|
|
//
|
2010-01-23 21:11:54 -08:00
|
|
|
// why is this the case? does anyone know? has anyone tried it on other gfx
|
|
|
|
// drivers?
|
2011-06-17 00:47:28 -07:00
|
|
|
//
|
2010-01-30 18:50:01 -08:00
|
|
|
//#define GLX_TEX_PIXMAP_RECREATE 1
|
2010-01-23 21:11:54 -08:00
|
|
|
|
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;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
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");
|
|
|
|
}
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
|
|
|
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
|
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");
|
2010-01-21 00:44:11 -08:00
|
|
|
# endif
|
|
|
|
#endif
|
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__, "");
|
|
|
|
}
|
2011-04-08 21:13:21 -07:00
|
|
|
return;
|
|
|
|
data = NULL;
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_native_unbind_cb(void *data, void *image)
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
Evas_GL_Image *im = image;
|
|
|
|
Native *n = im->native.data;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
// nothing
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
|
|
|
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
|
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");
|
2010-01-21 00:44:11 -08:00
|
|
|
# endif
|
|
|
|
#endif
|
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__, "");
|
|
|
|
}
|
2011-04-08 21:13:21 -07:00
|
|
|
return;
|
|
|
|
data = NULL;
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
|
|
|
|
2006-12-17 07:48:52 -08:00
|
|
|
static void
|
2010-01-21 00:44:11 -08:00
|
|
|
_native_free_cb(void *data, void *image)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
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;
|
2010-12-05 23:09:51 -08:00
|
|
|
|
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);
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
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");
|
|
|
|
}
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
|
|
|
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
|
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);
|
2010-02-16 20:21:59 -08:00
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
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;
|
|
|
|
}
|
2010-01-21 00:44:11 -08:00
|
|
|
# endif
|
|
|
|
#endif
|
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);
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
|
|
|
|
2010-08-02 23:09:53 -07:00
|
|
|
static void *
|
2010-01-21 00:44:11 -08:00
|
|
|
eng_image_native_set(void *data, void *image, void *native)
|
|
|
|
{
|
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
|
2011-04-04 03:23:12 -07:00
|
|
|
return NULL;
|
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;
|
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
|
|
|
|
|
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;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
if (target)
|
|
|
|
{
|
|
|
|
pixmap_att[i++] = GLX_TEXTURE_TARGET_EXT;
|
|
|
|
pixmap_att[i++] = target;
|
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
pixmap_att[i++] = 0;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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)
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
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);
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
2011-12-17 21:03:24 -08:00
|
|
|
if (target == GLX_TEXTURE_2D_EXT)
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
im->native.target = GL_TEXTURE_2D;
|
|
|
|
im->native.mipmap = re->win->depth_cfg[depth].mipmap;
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
2011-12-17 21:03:24 -08:00
|
|
|
# ifdef GL_TEXTURE_RECTANGLE_ARB
|
|
|
|
else if (target == GLX_TEXTURE_RECTANGLE_EXT)
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
im->native.target = GL_TEXTURE_RECTANGLE_ARB;
|
|
|
|
im->native.mipmap = 0;
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
2011-12-17 21:03:24 -08:00
|
|
|
# endif
|
2010-02-14 07:12:39 -08:00
|
|
|
else
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
im->native.target = GL_TEXTURE_2D;
|
|
|
|
im->native.mipmap = 0;
|
|
|
|
ERR("still unknown target");
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
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);
|
|
|
|
}
|
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
# endif
|
2010-01-21 00:44:11 -08:00
|
|
|
#endif
|
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;
|
2011-04-04 03:23:12 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
n->egl_surface = 0;
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
n->fbc = 0;
|
|
|
|
n->glx_pixmap = 0;
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
|
|
|
|
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;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
// FIXME: need to implement mapping sub texture regions
|
|
|
|
// x, y, w, h for possible texture atlasing
|
2011-04-04 03:23:12 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
evas_gl_common_image_native_enable(im);
|
|
|
|
}
|
|
|
|
}
|
2011-04-04 03:23:12 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
}
|
2010-08-02 23:09:53 -07:00
|
|
|
return im;
|
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)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
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);
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
|
2011-06-02 03:40:43 -07:00
|
|
|
#if 0 // filtering disabled
|
2011-04-18 22:47:56 -07:00
|
|
|
static void
|
|
|
|
eng_image_draw_filtered(void *data, void *context, void *surface,
|
2011-04-20 01:05:23 -07:00
|
|
|
void *image, Evas_Filter_Info *filter)
|
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;
|
|
|
|
|
2011-04-20 01:05:23 -07:00
|
|
|
evas_gl_common_filter_draw(re->win->gl_context, image, filter);
|
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);
|
|
|
|
}
|
2011-06-02 03:40:43 -07:00
|
|
|
#endif
|
2011-04-18 22:47:56 -07:00
|
|
|
|
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
//
|
|
|
|
//
|
|
|
|
/////////////////////////////////////////////////////////////////////////
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void *
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
2009-12-22 15:11:57 -08:00
|
|
|
*error = EVAS_LOAD_ERROR_NONE;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2009-12-22 15:11:57 -08:00
|
|
|
return evas_gl_common_image_load(re->win->gl_context, file, key, lo, error);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
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);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
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);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_image_free(void *data, void *image)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2003-09-04 00:40:34 -07:00
|
|
|
evas_gl_common_image_free(image);
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
*w = 0;
|
|
|
|
*h = 0;
|
|
|
|
return;
|
2006-12-19 06:12:40 -08:00
|
|
|
}
|
2010-01-21 01:42:26 -08:00
|
|
|
if (w) *w = ((Evas_GL_Image *)image)->w;
|
|
|
|
if (h) *h = ((Evas_GL_Image *)image)->h;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_image_size_set(void *data, void *image, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2010-01-21 01:42:26 -08:00
|
|
|
Evas_GL_Image *im = image;
|
|
|
|
Evas_GL_Image *im_old;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (!im) return NULL;
|
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
im->w = w;
|
|
|
|
im->h = h;
|
|
|
|
return image;
|
|
|
|
}
|
2006-12-19 06:12:40 -08:00
|
|
|
eng_window_use(re->win);
|
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;
|
2010-10-07 22:11:32 -07:00
|
|
|
im->w = w;
|
|
|
|
im->h = h;
|
2010-08-18 20:30:47 -07:00
|
|
|
im->tex = evas_gl_common_texture_dynamic_new(im->gc, im);
|
|
|
|
return image;
|
|
|
|
}
|
2003-09-04 00:40:34 -07:00
|
|
|
im_old = image;
|
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;
|
|
|
|
}
|
|
|
|
|
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))
|
2011-12-17 21:03:24 -08:00
|
|
|
return image;
|
2003-09-04 00:40:34 -07:00
|
|
|
if (im_old)
|
|
|
|
{
|
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));
|
|
|
|
/*
|
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();
|
|
|
|
}
|
|
|
|
*/
|
2009-10-09 05:10:27 -07:00
|
|
|
evas_gl_common_image_free(im_old);
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
2006-12-17 07:48:52 -08:00
|
|
|
else
|
2011-12-17 21:03:24 -08:00
|
|
|
im = evas_gl_common_image_new(re->win->gl_context, w, h, 1, EVAS_COLORSPACE_ARGB8888);
|
2003-09-04 00:40:34 -07:00
|
|
|
return im;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2009-12-19 22:23:13 -08:00
|
|
|
eng_image_dirty_region(void *data, void *image, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2010-01-21 01:42:26 -08:00
|
|
|
Evas_GL_Image *im = image;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data) return image;
|
2010-01-21 04:43:53 -08:00
|
|
|
eng_window_use(re->win);
|
2009-12-19 22:23:13 -08:00
|
|
|
evas_gl_common_image_dirty(image, x, y, w, h);
|
2003-09-04 00:40:34 -07:00
|
|
|
return image;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2011-05-19 04:19:22 -07:00
|
|
|
eng_image_data_get(void *data, void *image, int to_write, DATA32 **image_data, int *err)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2003-09-04 00:40:34 -07:00
|
|
|
Evas_GL_Image *im;
|
2011-05-19 04:19:22 -07:00
|
|
|
int error;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
*image_data = NULL;
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_GENERIC;
|
2011-11-10 00:59:09 -08:00
|
|
|
return NULL;
|
2006-12-19 06:12:40 -08:00
|
|
|
}
|
2003-09-04 00:40:34 -07:00
|
|
|
im = image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
*image_data = NULL;
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_NONE;
|
2010-01-21 01:42:26 -08:00
|
|
|
return im;
|
|
|
|
}
|
2011-08-16 00:06:36 -07:00
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
eng_window_use(re->win);
|
|
|
|
|
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))
|
2011-08-16 00:06:36 -07:00
|
|
|
{
|
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;
|
|
|
|
}
|
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)
|
|
|
|
{
|
2011-11-14 01:27:29 -08:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED;
|
2011-08-16 00:06:36 -07:00
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
2011-11-14 01:27:29 -08:00
|
|
|
return im;
|
2011-08-16 00:06:36 -07:00
|
|
|
}
|
2011-11-10 23:47:25 -08:00
|
|
|
im->tex->pt->dyn.checked_out++;
|
2011-08-16 00:06:36 -07:00
|
|
|
|
|
|
|
if (err) *err = EVAS_LOAD_ERROR_NONE;
|
|
|
|
return im;
|
|
|
|
}
|
|
|
|
#else
|
2010-08-13 03:39:41 -07:00
|
|
|
if ((im->tex) && (im->tex->pt) && (im->tex->pt->dyn.data))
|
2010-08-13 03:34:51 -07:00
|
|
|
{
|
|
|
|
*image_data = im->tex->pt->dyn.data;
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_NONE;
|
2010-08-13 03:34:51 -07:00
|
|
|
return im;
|
|
|
|
}
|
2011-08-16 00:06:36 -07:00
|
|
|
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
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 didnt 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,
|
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 didnt 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)
|
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 didnt 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
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
error = evas_cache_image_load_data(&im->im->cache_entry);
|
2006-12-17 07:48:52 -08:00
|
|
|
switch (im->cs.space)
|
2003-09-04 00:40:34 -07:00
|
|
|
{
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_ARGB8888:
|
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;
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_YCBCR422P601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P709_PL:
|
2011-08-23 08:13:40 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR422601_PL:
|
2011-08-29 13:56:48 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
|
2011-11-10 00:59:09 -08:00
|
|
|
*image_data = im->cs.data;
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
default:
|
2011-11-10 00:59:09 -08:00
|
|
|
abort();
|
|
|
|
break;
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = error;
|
2003-09-04 00:40:34 -07:00
|
|
|
return im;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_image_data_put(void *data, void *image, DATA32 *image_data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2006-12-17 08:46:30 -08:00
|
|
|
Evas_GL_Image *im, *im2;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2003-09-04 00:40:34 -07:00
|
|
|
im = image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data) return image;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
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))
|
2010-08-13 03:34:51 -07:00
|
|
|
{
|
2011-10-19 02:04:18 -07:00
|
|
|
int w, h;
|
|
|
|
|
2011-11-10 23:47:25 -08:00
|
|
|
if (im->tex->pt->dyn.data == image_data)
|
|
|
|
{
|
|
|
|
im->tex->pt->dyn.checked_out--;
|
2011-08-16 00:06:36 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
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);
|
2011-08-16 00:06:36 -07:00
|
|
|
#endif
|
2011-11-10 23:47:25 -08:00
|
|
|
return image;
|
|
|
|
}
|
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;
|
2010-08-13 03:34:51 -07:00
|
|
|
}
|
2006-12-17 07:48:52 -08:00
|
|
|
switch (im->cs.space)
|
2003-09-04 00:40:34 -07:00
|
|
|
{
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_ARGB8888:
|
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;
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_YCBCR422P601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P709_PL:
|
2011-08-23 08:13:40 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR422601_PL:
|
2011-08-29 13:56:48 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
|
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;
|
2006-12-17 07:48:52 -08:00
|
|
|
default:
|
2011-11-10 00:59:09 -08:00
|
|
|
abort();
|
|
|
|
break;
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
|
|
|
return im;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2008-09-16 07:52:57 -07:00
|
|
|
static void
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_image_data_preload_request(void *data __UNUSED__, void *image, const void *target)
|
2008-09-16 07:52:57 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *gim = image;
|
|
|
|
RGBA_Image *im;
|
|
|
|
|
2010-01-21 01:42:26 -08:00
|
|
|
if (!gim) return;
|
|
|
|
if (gim->native.data) return;
|
|
|
|
im = (RGBA_Image *)gim->im;
|
|
|
|
if (!im) return;
|
2008-09-16 07:52:57 -07:00
|
|
|
evas_cache_image_preload_data(&im->cache_entry, target);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_image_data_preload_cancel(void *data __UNUSED__, void *image, const void *target)
|
2008-09-16 07:52:57 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *gim = image;
|
|
|
|
RGBA_Image *im;
|
|
|
|
|
2010-01-21 01:42:26 -08:00
|
|
|
if (!gim) return;
|
|
|
|
if (gim->native.data) return;
|
|
|
|
im = (RGBA_Image *)gim->im;
|
|
|
|
if (!im) return;
|
2009-01-20 06:56:37 -08:00
|
|
|
evas_cache_image_preload_cancel(&im->cache_entry, target);
|
2008-09-16 07:52:57 -07:00
|
|
|
}
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
2006-09-30 03:18:37 -07:00
|
|
|
re->win->gl_context->dc = context;
|
|
|
|
evas_gl_common_image_draw(re->win->gl_context, image,
|
2009-10-09 05:10:27 -07:00
|
|
|
src_x, src_y, src_w, src_h,
|
|
|
|
dst_x, dst_y, dst_w, dst_h,
|
|
|
|
smooth);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2009-05-07 06:29:56 -07:00
|
|
|
static void
|
|
|
|
eng_image_scale_hint_set(void *data __UNUSED__, void *image, int hint)
|
|
|
|
{
|
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;
|
2009-05-07 06:29:56 -07:00
|
|
|
}
|
|
|
|
|
2009-11-06 03:32:23 -08:00
|
|
|
static void
|
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)
|
2009-11-06 03:32:23 -08:00
|
|
|
{
|
2010-09-18 07:23:20 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2009-11-11 03:39:25 -08:00
|
|
|
Render_Engine *re;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-11-11 03:39:25 -08:00
|
|
|
re = (Render_Engine *)data;
|
2010-09-18 07:23:20 -07:00
|
|
|
if (!image) return;
|
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;
|
2011-02-09 22:52:53 -08:00
|
|
|
if (npoints != 4)
|
|
|
|
{
|
2011-05-30 09:45:08 -07:00
|
|
|
// FIXME: nash - you didn't fix this
|
2011-02-09 22:52:53 -08:00
|
|
|
abort();
|
|
|
|
}
|
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;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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;
|
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);
|
2010-09-18 07:23:20 -07:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2011-02-09 22:52:53 -08:00
|
|
|
evas_gl_common_image_map_draw(re->win->gl_context, image, npoints, p,
|
|
|
|
smooth, level);
|
2010-09-18 07:23:20 -07:00
|
|
|
}
|
2009-11-06 03:32:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2011-06-09 12:25:21 -07:00
|
|
|
eng_image_map_surface_new(void *data, int w, int h, int alpha)
|
2009-11-06 03:32:23 -08:00
|
|
|
{
|
2009-11-12 23:22:31 -08:00
|
|
|
Render_Engine *re;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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);
|
2009-11-06 03:32:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
eng_image_map_surface_free(void *data __UNUSED__, void *surface)
|
|
|
|
{
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_image_free(surface);
|
2009-11-06 03:32:23 -08:00
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2009-05-07 06:29:56 -07:00
|
|
|
static int
|
2010-08-11 23:11:13 -07:00
|
|
|
eng_image_content_hint_get(void *data __UNUSED__, void *image)
|
2009-05-07 06:29:56 -07:00
|
|
|
{
|
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;
|
2009-05-07 06:29:56 -07:00
|
|
|
}
|
|
|
|
|
2011-02-08 03:41:38 -08:00
|
|
|
static void
|
2011-06-09 12:25:21 -07:00
|
|
|
eng_image_cache_flush(void *data)
|
2011-02-08 03:41:38 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
int tmp_size;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-02-08 03:41:38 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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
|
2011-06-09 12:25:21 -07:00
|
|
|
eng_image_cache_set(void *data, int bytes)
|
2011-02-08 03:41:38 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
|
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)
|
2010-08-18 20:30:47 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *im = image;
|
2011-06-09 12:25:21 -07:00
|
|
|
|
2010-09-18 17:28:58 -07:00
|
|
|
if ((im->tex) && (im->tex->pt->dyn.img))
|
2011-12-17 21:03:24 -08:00
|
|
|
*stride = im->tex->pt->dyn.stride;
|
2011-07-17 22:32:06 -07:00
|
|
|
else
|
2011-12-17 21:03:24 -08:00
|
|
|
*stride = im->w * 4;
|
2010-08-18 20:30:47 -07:00
|
|
|
}
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void
|
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)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
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;
|
2003-09-04 00:40:34 -07:00
|
|
|
{
|
2009-10-09 05:10:27 -07:00
|
|
|
// FIXME: put im into context so we can free it
|
2011-11-10 00:59:09 -08:00
|
|
|
static RGBA_Image *im = NULL;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-10-09 05:10:27 -07:00
|
|
|
if (!im)
|
2011-12-17 21:03:24 -08:00
|
|
|
im = (RGBA_Image *)evas_cache_image_empty(evas_common_image_cache_get());
|
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,
|
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,
|
2011-05-29 06:56:23 -07:00
|
|
|
intl_props);
|
2011-11-10 00:59:09 -08:00
|
|
|
evas_common_draw_context_font_ext_set(context,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2009-08-14 10:11:08 -07:00
|
|
|
static Eina_Bool
|
2011-06-28 01:11:07 -07:00
|
|
|
eng_canvas_alpha_get(void *data, void *info __UNUSED__)
|
2009-08-14 10:11:08 -07:00
|
|
|
{
|
2011-06-28 01:11:07 -07:00
|
|
|
Render_Engine *re = (Render_Engine *)data;
|
|
|
|
return re->win->alpha;
|
2009-08-14 10:11:08 -07:00
|
|
|
}
|
|
|
|
|
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...
|
|
|
|
switch(cfg->color_format)
|
2011-06-17 00:47:28 -07:00
|
|
|
{
|
2011-10-28 04:08:23 -07:00
|
|
|
case EVAS_GL_RGB_888:
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->rt_fmt = GL_RGB;
|
|
|
|
sfc->rt_internal_fmt = GL_RGB;
|
|
|
|
break;
|
2011-10-28 04:08:23 -07:00
|
|
|
case EVAS_GL_RGBA_8888:
|
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)
|
2011-06-17 00:47:28 -07:00
|
|
|
{
|
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:
|
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
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->rb_depth_fmt = GL_DEPTH_COMPONENT;
|
2011-05-18 02:49:58 -07:00
|
|
|
#endif
|
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)
|
2011-06-17 00:47:28 -07:00
|
|
|
{
|
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:
|
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
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->rb_stencil_fmt = GL_STENCIL_INDEX;
|
2011-05-18 02:49:58 -07:00
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
break;
|
|
|
|
case EVAS_GL_STENCIL_BIT_16:
|
|
|
|
default:
|
|
|
|
ERR("Unsupported Stencil Bits Format!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
// Do Packed Depth24_Stencil8 Later...
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-06-17 00:47:28 -07:00
|
|
|
_create_rt_buffers(Render_Engine *data __UNUSED__,
|
2011-04-04 03:23:12 -07:00
|
|
|
Render_Engine_GL_Surface *sfc)
|
|
|
|
{
|
|
|
|
// Render Target texture
|
2011-12-17 21:03:24 -08:00
|
|
|
glGenTextures(1, &sfc->rt_tex );
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
// Depth RenderBuffer - Create storage here...
|
|
|
|
if (sfc->depth_bits != EVAS_GL_DEPTH_NONE)
|
2011-12-17 21:03:24 -08:00
|
|
|
glGenRenderbuffers(1, &sfc->rb_depth);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
// Stencil RenderBuffer - Create Storage here...
|
|
|
|
if (sfc->stencil_bits != EVAS_GL_STENCIL_NONE)
|
2011-12-17 21:03:24 -08:00
|
|
|
glGenRenderbuffers(1, &sfc->rb_stencil);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-06-17 00:47:28 -07:00
|
|
|
_attach_fbo_surface(Render_Engine *data __UNUSED__,
|
|
|
|
Render_Engine_GL_Surface *sfc,
|
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
|
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
|
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);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
// Depth RenderBuffer - Attach it to FBO
|
|
|
|
if (sfc->depth_bits != EVAS_GL_DEPTH_NONE)
|
|
|
|
{
|
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);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Stencil RenderBuffer - Attach it to FBO
|
|
|
|
if (sfc->stencil_bits != EVAS_GL_STENCIL_NONE)
|
|
|
|
{
|
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);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Check FBO for completeness
|
2011-12-17 21:03:24 -08:00
|
|
|
fb_status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
|
2011-06-17 00:47:28 -07:00
|
|
|
if (fb_status != GL_FRAMEBUFFER_COMPLETE)
|
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
|
|
|
|
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;
|
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;
|
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;
|
2011-05-18 02:49:58 -07:00
|
|
|
sfc->fbo_attached = 0;
|
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;
|
|
|
|
|
|
|
|
// Set the internal format based on the config
|
|
|
|
if (!_set_internal_config(sfc, cfg))
|
|
|
|
{
|
|
|
|
ERR("Unsupported Format!");
|
|
|
|
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
|
|
|
// 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)
|
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
|
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)
|
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
|
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
|
|
|
}
|
|
|
|
|
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;
|
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;
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = eglMakeCurrent(re->win->egl_disp, rsc->surface, rsc->surface, rsc->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = glXMakeCurrent(re->info->info.display, re->win->win, rsc->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glDeleteTextures(1, &sfc->rt_tex);
|
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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glDeleteRenderbuffers(1, &sfc->rb_depth);
|
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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glDeleteRenderbuffers(1, &sfc->rb_stencil);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = glXMakeCurrent(re->info->info.display, None, NULL);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
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);
|
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];
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
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)
|
|
|
|
{
|
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);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
else
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
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);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ctx->context)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
ERR("eglCreateContext() fail. code=%#x", eglGetError());
|
2011-04-04 03:23:12 -07:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
// GLX
|
|
|
|
if (share_context)
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
ctx->context = glXCreateContext(re->info->info.display,
|
|
|
|
re->win->visualinfo,
|
|
|
|
share_ctx->context, // Share Context
|
|
|
|
1);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
else
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
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);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ctx->context)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("glXCreateContext() fail.");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ctx->initialized = 0;
|
2011-08-24 23:30:52 -07:00
|
|
|
ctx->context_fbo = 0;
|
2011-05-18 02:49:58 -07:00
|
|
|
ctx->current_sfc = NULL;
|
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;
|
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;
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
// 1. Do a make current with the given context
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = eglMakeCurrent(re->win->egl_disp, rsc->surface,
|
|
|
|
rsc->surface, ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = glXMakeCurrent(re->info->info.display, re->win->win,
|
|
|
|
ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// 2. 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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glDeleteFramebuffers(1, &ctx->context_fbo);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
// 3. Destroy the Context
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
eglDestroyContext(re->win->egl_disp, ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
ctx->context = EGL_NO_CONTEXT;
|
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE,
|
|
|
|
EGL_NO_SURFACE, EGL_NO_CONTEXT);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
glXDestroyContext(re->info->info.display, ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
ctx->context = 0;
|
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = glXMakeCurrent(re->info->info.display, None, NULL);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
free(ctx);
|
|
|
|
context = NULL;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-10-25 05:07:56 -07:00
|
|
|
eng_gl_make_current(void *data __UNUSED__, void *surface, void *context)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Render_Engine_GL_Surface *sfc;
|
|
|
|
Render_Engine_GL_Context *ctx;
|
2011-05-19 04:19:22 -07:00
|
|
|
int ret = 0;
|
2011-10-29 22:02:05 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
Render_Engine_GL_Resource *rsc;
|
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
sfc = (Render_Engine_GL_Surface*)surface;
|
|
|
|
ctx = (Render_Engine_GL_Context*)context;
|
|
|
|
|
2011-05-18 02:49:58 -07:00
|
|
|
// Unset surface/context
|
2011-04-04 03:23:12 -07:00
|
|
|
if ((!sfc) || (!ctx))
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE,
|
|
|
|
EGL_NO_SURFACE, EGL_NO_CONTEXT);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = glXMakeCurrent(re->info->info.display, None, NULL);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
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;
|
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;
|
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
|
|
|
// Do a make current only if it's not already current
|
2011-04-04 03:23:12 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
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 = eina_tls_get(resource_key)) == EINA_FALSE) return 0;
|
2011-08-24 23:30:52 -07:00
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
if ((eglGetCurrentContext() != ctx->context) ||
|
|
|
|
(eglGetCurrentSurface(EGL_READ) != rsc->surface) ||
|
|
|
|
(eglGetCurrentSurface(EGL_DRAW) != rsc->surface) )
|
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
|
|
|
// Flush remainder of what's in Evas' pipeline
|
|
|
|
if (re->win) eng_window_use(NULL);
|
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
|
|
|
// Do a make current
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = eglMakeCurrent(re->win->egl_disp, rsc->surface,
|
|
|
|
rsc->surface, 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
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
2011-08-24 23:30:52 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
if ((glXGetCurrentContext() != ctx->context) ||
|
|
|
|
(glXGetCurrentDrawable() != re->win->win) )
|
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
|
|
|
// Flush remainder of what's in Evas' pipeline
|
|
|
|
if (re->win) eng_window_use(NULL);
|
|
|
|
|
|
|
|
// Do a make current
|
2011-12-17 21:03:24 -08:00
|
|
|
ret = glXMakeCurrent(re->info->info.display, re->win->win, ctx->context);
|
2011-11-10 00:59:09 -08:00
|
|
|
if (!ret)
|
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("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
2011-08-24 23:30:52 -07:00
|
|
|
}
|
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
|
2011-05-18 02:49:58 -07:00
|
|
|
// Create FBO if not already created
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ctx->initialized)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
glGenFramebuffers(1, &ctx->context_fbo);
|
2011-05-18 02:49:58 -07:00
|
|
|
ctx->initialized = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Attach FBO if it hasn't been attached or if surface changed
|
2011-08-24 23:30:52 -07:00
|
|
|
if ((!sfc->fbo_attached) || (ctx->current_sfc != sfc))
|
2011-05-18 02:49:58 -07:00
|
|
|
{
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!_attach_fbo_surface(re, sfc, ctx))
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
2011-05-18 02:49:58 -07:00
|
|
|
ERR("_attach_fbo_surface() failed.");
|
2011-04-04 03:23:12 -07:00
|
|
|
return 0;
|
|
|
|
}
|
2011-08-24 23:30:52 -07:00
|
|
|
|
|
|
|
if (ctx->current_fbo)
|
|
|
|
// Bind to the previously bound buffer
|
2011-12-17 21:03:24 -08:00
|
|
|
glBindFramebuffer(GL_FRAMEBUFFER, ctx->current_fbo);
|
2011-08-24 23:30:52 -07:00
|
|
|
else
|
|
|
|
// Bind FBO
|
2011-12-17 21:03:24 -08:00
|
|
|
glBindFramebuffer(GL_FRAMEBUFFER, ctx->context_fbo);
|
2011-08-24 23:30:52 -07:00
|
|
|
|
2011-05-18 02:49:58 -07:00
|
|
|
sfc->fbo_attached = 1;
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
// Set the current surface/context
|
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;
|
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 *
|
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;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
static int
|
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;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
ns->type = EVAS_NATIVE_SURFACE_OPENGL;
|
|
|
|
ns->version = EVAS_NATIVE_SURFACE_VERSION;
|
|
|
|
ns->data.opengl.texture_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;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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
|
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
|
|
|
}
|
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
static void
|
|
|
|
evgl_glBindFramebuffer(GLenum target, GLuint framebuffer)
|
|
|
|
{
|
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)
|
|
|
|
{
|
|
|
|
if (ctx)
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
glBindFramebuffer(target, ctx->context_fbo);
|
2011-08-24 23:30:52 -07:00
|
|
|
ctx->current_fbo = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
glBindFramebuffer(target, framebuffer);
|
2011-08-24 23:30:52 -07:00
|
|
|
|
|
|
|
// Save this for restore when doing make current
|
|
|
|
if (ctx)
|
|
|
|
ctx->current_fbo = framebuffer;
|
|
|
|
}
|
2011-05-01 19:14:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glBindRenderbuffer(GLenum target, GLuint renderbuffer)
|
|
|
|
{
|
|
|
|
// Add logic to take care when renderbuffer=0
|
2011-08-24 23:30:52 -07:00
|
|
|
// On a second thought we don't need this
|
2011-12-17 21:03:24 -08:00
|
|
|
glBindRenderbuffer(target, renderbuffer);
|
2011-05-01 19:14:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glClearDepthf(GLclampf depth)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-12-17 21:03:24 -08:00
|
|
|
glClearDepthf(depth);
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
glClearDepth(depth);
|
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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glDepthRangef(zNear, zFar);
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
glDepthRange(zNear, zFar);
|
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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glGetShaderPrecisionFormat(shadertype, precisiontype, range, precision);
|
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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glReleaseShaderCompiler();
|
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)
|
2011-12-17 21:03:24 -08:00
|
|
|
glShaderBinary(n, shaders, binaryformat, binary, length);
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
2011-12-17 21:03:24 -08:00
|
|
|
// FIXME: need to dlsym/getprocaddress for this
|
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
|
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
|
|
|
}
|
|
|
|
|
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)
|
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
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
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
|
|
|
//--------------------------------//
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
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);
|
|
|
|
ORD(glClear);
|
|
|
|
ORD(glClearColor);
|
2011-12-17 21:03:24 -08:00
|
|
|
// ORD(glClearDepthf);
|
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);
|
2011-12-17 21:03:24 -08:00
|
|
|
// ORD(glDepthRangef);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glDetachShader);
|
|
|
|
ORD(glDisable);
|
|
|
|
ORD(glDisableVertexAttribArray);
|
|
|
|
ORD(glDrawArrays);
|
|
|
|
ORD(glDrawElements);
|
|
|
|
ORD(glEnable);
|
|
|
|
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);
|
2011-12-17 21:03:24 -08:00
|
|
|
// ORD(glGetShaderPrecisionFormat);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glGetShaderSource);
|
2011-12-17 21:03:24 -08:00
|
|
|
// ORD(glGetString);
|
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);
|
2011-12-17 21:03:24 -08:00
|
|
|
// ORD(glReleaseShaderCompiler);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glRenderbufferStorage);
|
|
|
|
ORD(glSampleCoverage);
|
|
|
|
ORD(glScissor);
|
2011-12-17 21:03:24 -08:00
|
|
|
// ORD(glShaderBinary);
|
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);
|
|
|
|
ORD(glViewport);
|
|
|
|
#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
|
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
|
|
|
|
|
2011-12-17 21:03:24 -08:00
|
|
|
// Override functions wrapped by Evas_GL
|
2011-05-01 19:14:00 -07:00
|
|
|
#define ORD(f) EVAS_API_OVERRIDE(f, &gl_funcs, evgl_)
|
2011-06-17 00:47:28 -07:00
|
|
|
ORD(glBindFramebuffer);
|
|
|
|
ORD(glBindRenderbuffer);
|
|
|
|
|
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
|
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);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
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
|
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
return &gl_funcs;
|
|
|
|
}
|
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
static int
|
|
|
|
eng_image_load_error_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
|
|
|
Evas_GL_Image *im;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
if (!image) return EVAS_LOAD_ERROR_NONE;
|
|
|
|
im = image;
|
|
|
|
return im->im->cache_entry.load_error;
|
|
|
|
}
|
2011-05-01 19:14:00 -07:00
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
static Eina_Bool
|
|
|
|
eng_image_animated_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return EINA_FALSE;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return EINA_FALSE;
|
|
|
|
|
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)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return -1;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return -1;
|
|
|
|
|
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)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
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;
|
|
|
|
|
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)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return -1;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return -1;
|
|
|
|
|
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)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return -1;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return -1;
|
|
|
|
|
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)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return EINA_FALSE;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return EINA_FALSE;
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2011-12-13 08:58:20 -08:00
|
|
|
static Eina_Bool
|
2011-12-14 10:52:42 -08:00
|
|
|
eng_image_can_region_get(void *data __UNUSED__, void *image)
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2009-06-16 06:01:36 -07:00
|
|
|
static int
|
2006-09-06 00:28:46 -07:00
|
|
|
module_open(Evas_Module *em)
|
2006-01-14 04:13:38 -08:00
|
|
|
{
|
2010-04-29 08:32:47 -07:00
|
|
|
static Eina_Bool xrm_inited = EINA_FALSE;
|
|
|
|
if (!xrm_inited)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
xrm_inited = EINA_TRUE;
|
|
|
|
XrmInitialize();
|
2010-04-29 08:32:47 -07:00
|
|
|
}
|
|
|
|
|
2006-01-14 04:13:38 -08:00
|
|
|
if (!em) return 0;
|
2010-10-07 16:46:42 -07:00
|
|
|
if (!evas_gl_common_module_open()) return 0;
|
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;
|
2009-11-13 00:28:47 -08:00
|
|
|
if (_evas_engine_GL_X11_log_dom < 0)
|
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);
|
2009-11-13 00:28:47 -08:00
|
|
|
if (_evas_engine_GL_X11_log_dom < 0)
|
2009-10-22 08:22:22 -07:00
|
|
|
{
|
2010-10-07 16:46:42 -07:00
|
|
|
EINA_LOG_ERR("Can not create a module log domain.");
|
2009-11-13 00:28:47 -08:00
|
|
|
return 0;
|
2009-10-22 08:22:22 -07:00
|
|
|
}
|
2006-12-09 00:52:08 -08:00
|
|
|
/* store it for later use */
|
|
|
|
func = pfunc;
|
|
|
|
/* now to override methods */
|
2011-12-17 21:03:24 -08:00
|
|
|
#define ORD(f) EVAS_API_OVERRIDE(f, &func, eng_)
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(info);
|
|
|
|
ORD(info_free);
|
|
|
|
ORD(setup);
|
2009-08-14 10:11:08 -07:00
|
|
|
ORD(canvas_alpha_get);
|
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);
|
2007-06-16 19:56:59 -07:00
|
|
|
ORD(output_idle_flush);
|
2010-04-12 01:23:53 -07:00
|
|
|
ORD(output_dump);
|
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);
|
2008-08-25 22:45:04 -07:00
|
|
|
|
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);
|
2008-09-16 07:52:57 -07:00
|
|
|
ORD(image_data_preload_request);
|
|
|
|
ORD(image_data_preload_cancel);
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(image_alpha_set);
|
|
|
|
ORD(image_alpha_get);
|
2008-11-04 01:19:35 -08:00
|
|
|
ORD(image_border_set);
|
|
|
|
ORD(image_border_get);
|
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);
|
2011-12-23 04:00:52 -08:00
|
|
|
ORD(image_can_region_get);
|
2011-04-05 22:38:38 -07:00
|
|
|
ORD(image_mask_create);
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(image_native_set);
|
|
|
|
ORD(image_native_get);
|
2011-06-02 03:40:43 -07:00
|
|
|
#if 0 // filtering disabled
|
2011-04-18 22:47:56 -07:00
|
|
|
ORD(image_draw_filtered);
|
|
|
|
ORD(image_filtered_get);
|
|
|
|
ORD(image_filtered_save);
|
|
|
|
ORD(image_filtered_free);
|
2011-06-02 03:40:43 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(font_draw);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-05-07 06:29:56 -07:00
|
|
|
ORD(image_scale_hint_set);
|
|
|
|
ORD(image_scale_hint_get);
|
2010-08-18 20:30:47 -07:00
|
|
|
ORD(image_stride_get);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-02-06 15:52:17 -08:00
|
|
|
ORD(image_map_draw);
|
2009-11-06 03:32:23 -08:00
|
|
|
ORD(image_map_surface_new);
|
|
|
|
ORD(image_map_surface_free);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-08-11 23:11:13 -07:00
|
|
|
ORD(image_content_hint_set);
|
|
|
|
ORD(image_content_hint_get);
|
2011-02-08 03:41:38 -08:00
|
|
|
|
|
|
|
ORD(image_cache_flush);
|
|
|
|
ORD(image_cache_set);
|
|
|
|
ORD(image_cache_get);
|
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);
|
2011-04-04 03:23:12 -07:00
|
|
|
ORD(gl_proc_address_get);
|
|
|
|
ORD(gl_native_surface_get);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(gl_api_get);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
ORD(image_load_error_get);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
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);
|
|
|
|
|
2011-10-21 01:17:14 -07:00
|
|
|
ORD(image_max_size_get);
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2006-12-09 00:52:08 -08:00
|
|
|
/* now advertise out own api */
|
|
|
|
em->functions = (void *)(&func);
|
2006-01-14 04:13:38 -08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
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__)
|
2006-01-14 04:13:38 -08:00
|
|
|
{
|
2009-10-22 08:22:22 -07:00
|
|
|
eina_log_domain_unregister(_evas_engine_GL_X11_log_dom);
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
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;
|
|
|
|
}
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2010-10-07 16:46:42 -07:00
|
|
|
evas_gl_common_module_close();
|
2006-01-14 04:13:38 -08:00
|
|
|
}
|
|
|
|
|
2009-06-16 06:01:36 -07:00
|
|
|
static Evas_Module_Api evas_modapi =
|
2006-01-14 04:13:38 -08:00
|
|
|
{
|
|
|
|
EVAS_MODULE_API_VERSION,
|
2009-06-16 06:01:36 -07:00
|
|
|
"gl_x11",
|
|
|
|
"none",
|
|
|
|
{
|
2011-12-17 21:03:24 -08:00
|
|
|
module_open,
|
|
|
|
module_close
|
2009-06-16 06:01:36 -07:00
|
|
|
}
|
2006-01-14 04:13:38 -08:00
|
|
|
};
|
2009-06-16 06:01:36 -07:00
|
|
|
|
|
|
|
EVAS_MODULE_DEFINE(EVAS_MODULE_TYPE_ENGINE, engine, gl_x11);
|
|
|
|
|
2011-07-08 18:47:01 -07:00
|
|
|
#ifndef EVAS_STATIC_BUILD_GL_XLIB
|
2009-06-16 06:01:36 -07:00
|
|
|
EVAS_EINA_MODULE_DEFINE(engine, gl_x11);
|
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
/* vim:set ts=8 sw=3 sts=3 expandtab cino=>5n-2f0^-2{2(0W1st0 :*/
|