[E-devel] [Patch] ELM GLView updates
Hi all,
Upon reviewing the elm_glview, I've realized a few issues and mistakes that i've
made originally so I've made some changes/ updates to elm_glview
1.) GL Resource Deletion in ELM_GLView
In order to delete GL resources, the current approach simply registered a
delete callback to the GLView object and handled resource deletion there.
Unfortunately, using the delete callback did not guarantee the glview
context to be
current. In order to guarantee that the current context was the glview context,
the make_current call needs to be called explicitly. Since we were
hiding all the
make current details in elm_glview, i've decided to add an API that registers a
delete callback function. I know that this may seem redundant since
there is already
a delete callback that you can register with glview objects.
Unfortunately, this is the
only option that we have apart from exposing make_current, which is
something that
went again what we are trying to do with elm_glview.
Since adding delete callback alone seemed a little out of place, i've
taken the liberty
to add other callback functions to make it seem consistent.
void elm_glview_init_func_set(Evas_Object *obj, Elm_GLView_Func func);
void elm_glview_del_func_set(Evas_Object *obj, Elm_GLView_Func func);
void elm_glview_resize_func_set(Evas_Object *obj, Elm_GLView_Func func);
resize callback can be controversial as well but I want to argue that
adding this callback
makes the render function a lot cleaner. To handle resize
differently, the user in
render function needs to manually compare and see if the size has changed, and
then handle the cases. Doing all of this internally once makes the
developers life
a lot easier in my opinion.
these callback functions do make the render function a lot cleaner.
You can check
out the updated test_glview.c or newly added test_glview_simple.
2.) Minor bug fixes/changes
elm_glview_scale_policy_set() was supposed to be elm_glview_resize_policy_set()
but it somehow evaded our reviews. That has been fixed.
Also, in _glview_resize, after updating the surface, it was explicitly
calling the
render function. It is actually unnecessary here and calling it here
will cause
problems if resize gets called before everything else is setup
properly. So that has
been commented out.
3.) test_glview & test_glview_simple
elementary_test case for glview has been updated to reflect the api changes.
when you run the elmentary_test, you need to make sure that you set
ELM_ENGINE=gl as glview currently only runs on gl backend.
test_glview runs the gears example. For testing purposes I've included a simple
glview test case that renders a triangle and changing background color.
4.) Attached Files: elm_glview_update.patch, test_glview_simple.c
- copy test_glview_simple.c to elementary/src/bin directory
- apply patch using patch -p0 elm_glview_update.patch
- Do make, make install
- run by
%ELM_ENGINE=gl elmentary_test
Comments and suggestions would be much appreciated.
thanks a bunch!
Sung
elm_glview_update.patch
Description: Binary data
#include
#ifdef HAVE_CONFIG_H
# include "elementary_config.h"
#endif
#ifndef ELM_LIB_QUICKLAUNCH
typedef struct _GLData GLData;
// GL related data here..
struct _GLData
{
Evas_GL_API *glapi;
GLuint program;
GLuint vtx_shader;
GLuint fgmt_shader;
GLuint vbo;
int initialized : 1;
};
static float red = 1.0;
////
static GLuint
load_shader( GLData *gld, GLenum type, const char *shader_src )
{
Evas_GL_API *gl = gld->glapi;
GLuint shader;
GLint compiled;
// Create the shader object
shader = gl->glCreateShader(type);
if (shader==0)
return 0;
// Load/Compile shader source
gl->glShaderSource(shader, 1, &shader_src, NULL);
gl->glCompileShader(shader);
gl->glGetShaderiv(shader, GL_COMPILE_STATUS, &compiled);
if (!compiled)
{
GLint info_len = 0;
gl->glGetShaderiv(shader, GL_INFO_LOG_LENGTH, &info_len);
if (info_len > 1)
{
char* info_log = malloc(sizeof(char) * info_len);
gl->glGetShaderInfoLog(shader, info_len, NULL, info_log);
printf("Error compiling shader:\n%s\n", info_log );
free(info_log);
}
gl->glDeleteShader(shader);
return 0;
}
return shader;
}
// Initialize the shader and program object
static int
init_shaders(GLData *gld)
{
Evas_GL_API *gl = gld->glapi;
GLbyte vShaderStr[] =
"attribute vec4 vPosition;\n"
"void main() \n"
"{\n"
" gl_Position = vPosition; \n"
"}\n";
GLbyte fShaderStr[] =
"precision mediump float;\n"\
"void main() \n"
"{\n"
" gl_FragColor = vec4 ( 1.0, 0.0, 0.0, 1.0 );\n"
"}
Re: [E-devel] [Patch] ELM GLView updates
On Mon, 20 Jun 2011 11:18:56 +0900 "Sung W. Park" said: in svn as it pretty much fixes things. comments here; 1. not totally into the idea of setting engine explicitly before u create the window :( if its not a gl engine this test cant really work and that config is controls system-wide for gl apps atm. this SHOULD work without the gl engine via a software mesa fallback so setting the engine kind of will hide that fact that that isnt done yet :) 2. thought i really don't like the resize callback i'll let it pass as this is some kind of bastard son of both efl and opengl and there isn't really a pure "one true way" and there is very little you can do to make both sides totally happy as there is a fundamental design philosophy difference between them in certain areas :( > Hi all, > > Upon reviewing the elm_glview, I've realized a few issues and mistakes that > i've made originally so I've made some changes/ updates to elm_glview > > 1.) GL Resource Deletion in ELM_GLView > > In order to delete GL resources, the current approach simply registered a > delete callback to the GLView object and handled resource deletion there. > Unfortunately, using the delete callback did not guarantee the glview > context to be > current. In order to guarantee that the current context was the glview > context, the make_current call needs to be called explicitly. Since we were > hiding all the > make current details in elm_glview, i've decided to add an API that registers > a delete callback function. I know that this may seem redundant since > there is already > a delete callback that you can register with glview objects. > Unfortunately, this is the > only option that we have apart from exposing make_current, which is > something that > went again what we are trying to do with elm_glview. > > Since adding delete callback alone seemed a little out of place, i've > taken the liberty > to add other callback functions to make it seem consistent. > > void elm_glview_init_func_set(Evas_Object *obj, Elm_GLView_Func func); > void elm_glview_del_func_set(Evas_Object *obj, Elm_GLView_Func func); > void elm_glview_resize_func_set(Evas_Object *obj, Elm_GLView_Func func); > > resize callback can be controversial as well but I want to argue that > adding this callback > makes the render function a lot cleaner. To handle resize > differently, the user in > render function needs to manually compare and see if the size has changed, and > then handle the cases. Doing all of this internally once makes the > developers life > a lot easier in my opinion. > > these callback functions do make the render function a lot cleaner. > You can check > out the updated test_glview.c or newly added test_glview_simple. > > 2.) Minor bug fixes/changes > > elm_glview_scale_policy_set() was supposed to be elm_glview_resize_policy_set > () but it somehow evaded our reviews. That has been fixed. > > Also, in _glview_resize, after updating the surface, it was explicitly > calling the > render function. It is actually unnecessary here and calling it here > will cause > problems if resize gets called before everything else is setup > properly. So that has > been commented out. > > 3.) test_glview & test_glview_simple > > elementary_test case for glview has been updated to reflect the api changes. > when you run the elmentary_test, you need to make sure that you set > ELM_ENGINE=gl as glview currently only runs on gl backend. > > test_glview runs the gears example. For testing purposes I've included a > simple glview test case that renders a triangle and changing background color. > > 4.) Attached Files: elm_glview_update.patch, test_glview_simple.c > - copy test_glview_simple.c to elementary/src/bin directory > - apply patch using patch -p0 elm_glview_update.patch > - Do make, make install > - run by > %ELM_ENGINE=gl elmentary_test > > > Comments and suggestions would be much appreciated. > > thanks a bunch! > Sung -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] ELM GLView updates
cool, thanks! well hopefully we'll have the software-backend running GL stuff as well soon. I think we can do but it'll take time for me to get to it, unless someones gets on it before I do. I hear ya on the bastard son. we hate it but sometimes it happens aswe try to bring two together. Hopefully we won't see many more of those. anyway, looking forward to more comments and suggestions on how we can make the GL stuff better on EFL. cheers, Sung yeah, i hear ya on the callbacks here, especially the resize. On Mon, Jun 20, 2011 at 7:57 PM, Carsten Haitzler wrote: > On Mon, 20 Jun 2011 11:18:56 +0900 "Sung W. Park" > said: > > in svn as it pretty much fixes things. comments here; > > 1. not totally into the idea of setting engine explicitly before u create > the > window :( if its not a gl engine this test cant really work and that config > is > controls system-wide for gl apps atm. this SHOULD work without the gl > engine > via a software mesa fallback so setting the engine kind of will hide that > fact > that that isnt done yet :) > 2. thought i really don't like the resize callback i'll let it pass as this > is > some kind of bastard son of both efl and opengl and there isn't really a > pure > "one true way" and there is very little you can do to make both sides > totally > happy as there is a fundamental design philosophy difference between them > in > certain areas :( > > > Hi all, > > > > Upon reviewing the elm_glview, I've realized a few issues and mistakes > that > > i've made originally so I've made some changes/ updates to elm_glview > > > > 1.) GL Resource Deletion in ELM_GLView > > > > In order to delete GL resources, the current approach simply registered a > > delete callback to the GLView object and handled resource deletion there. > > Unfortunately, using the delete callback did not guarantee the glview > > context to be > > current. In order to guarantee that the current context was the glview > > context, the make_current call needs to be called explicitly. Since we > were > > hiding all the > > make current details in elm_glview, i've decided to add an API that > registers > > a delete callback function. I know that this may seem redundant since > > there is already > > a delete callback that you can register with glview objects. > > Unfortunately, this is the > > only option that we have apart from exposing make_current, which is > > something that > > went again what we are trying to do with elm_glview. > > > > Since adding delete callback alone seemed a little out of place, i've > > taken the liberty > > to add other callback functions to make it seem consistent. > > > > void elm_glview_init_func_set(Evas_Object *obj, Elm_GLView_Func func); > > void elm_glview_del_func_set(Evas_Object *obj, Elm_GLView_Func func); > > void elm_glview_resize_func_set(Evas_Object *obj, Elm_GLView_Func func); > > > > resize callback can be controversial as well but I want to argue that > > adding this callback > > makes the render function a lot cleaner. To handle resize > > differently, the user in > > render function needs to manually compare and see if the size has > changed, and > > then handle the cases. Doing all of this internally once makes the > > developers life > > a lot easier in my opinion. > > > > these callback functions do make the render function a lot cleaner. > > You can check > > out the updated test_glview.c or newly added test_glview_simple. > > > > 2.) Minor bug fixes/changes > > > > elm_glview_scale_policy_set() was supposed to be > elm_glview_resize_policy_set > > () but it somehow evaded our reviews. That has been fixed. > > > > Also, in _glview_resize, after updating the surface, it was explicitly > > calling the > > render function. It is actually unnecessary here and calling it here > > will cause > > problems if resize gets called before everything else is setup > > properly. So that has > > been commented out. > > > > 3.) test_glview & test_glview_simple > > > > elementary_test case for glview has been updated to reflect the api > changes. > > when you run the elmentary_test, you need to make sure that you set > > ELM_ENGINE=gl as glview currently only runs on gl backend. > > > > test_glview runs the gears example. For testing purposes I've included a > > simple glview test case that renders a triangle and changing background > color. > > > > 4.) Attached Files: elm_glview_update.patch, test_glview_simple.c > > - copy test_glview_simple.c to elementary/src/bin directory > > - apply patch using patch -p0 elm_glview_update.patch > > - Do make, make install > > - run by > > %ELM_ENGINE=gl elmentary_test > > > > > > Comments and suggestions would be much appreciated. > > > > thanks a bunch! > > Sung > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > -- EditLive Enterprise is the wo
Re: [E-devel] [Patch] ELM GLView updates
On Tue, 21 Jun 2011 09:45:26 +0900 "Sung W. Park" said: > cool, thanks! > > well hopefully we'll have the software-backend running GL stuff as well > soon. > I think we can do but it'll take time for me to get to it, unless > someones gets on > it before I do. sure. understood there. > I hear ya on the bastard son. we hate it but sometimes it happens aswe try > to > bring two together. Hopefully we won't see many more of those. i hope so too. > anyway, looking forward to more comments and suggestions on how we can make > the GL stuff better on EFL. well we COULD provide brand new api's in ADDITON to normal GL.. eg async texture upload api's... we can make full use of eavs's image loading infra and provide a direct "upload image data from image object X to texture" so people can just make image obj, set file, then "upload texture" on the gl side. that'd save developers LOTS of trouble. also throw in conveniences like "upload text to texture" so they dont have to do their own text rendering work... :) this is where evas will pull away from regular gl and become signficantly more usable. > cheers, > Sung > > yeah, i hear ya on the callbacks here, especially the resize. > > On Mon, Jun 20, 2011 at 7:57 PM, Carsten Haitzler wrote: > > > On Mon, 20 Jun 2011 11:18:56 +0900 "Sung W. Park" > > said: > > > > in svn as it pretty much fixes things. comments here; > > > > 1. not totally into the idea of setting engine explicitly before u create > > the > > window :( if its not a gl engine this test cant really work and that config > > is > > controls system-wide for gl apps atm. this SHOULD work without the gl > > engine > > via a software mesa fallback so setting the engine kind of will hide that > > fact > > that that isnt done yet :) > > 2. thought i really don't like the resize callback i'll let it pass as this > > is > > some kind of bastard son of both efl and opengl and there isn't really a > > pure > > "one true way" and there is very little you can do to make both sides > > totally > > happy as there is a fundamental design philosophy difference between them > > in > > certain areas :( > > > > > Hi all, > > > > > > Upon reviewing the elm_glview, I've realized a few issues and mistakes > > that > > > i've made originally so I've made some changes/ updates to elm_glview > > > > > > 1.) GL Resource Deletion in ELM_GLView > > > > > > In order to delete GL resources, the current approach simply registered a > > > delete callback to the GLView object and handled resource deletion there. > > > Unfortunately, using the delete callback did not guarantee the glview > > > context to be > > > current. In order to guarantee that the current context was the glview > > > context, the make_current call needs to be called explicitly. Since we > > were > > > hiding all the > > > make current details in elm_glview, i've decided to add an API that > > registers > > > a delete callback function. I know that this may seem redundant since > > > there is already > > > a delete callback that you can register with glview objects. > > > Unfortunately, this is the > > > only option that we have apart from exposing make_current, which is > > > something that > > > went again what we are trying to do with elm_glview. > > > > > > Since adding delete callback alone seemed a little out of place, i've > > > taken the liberty > > > to add other callback functions to make it seem consistent. > > > > > > void elm_glview_init_func_set(Evas_Object *obj, Elm_GLView_Func func); > > > void elm_glview_del_func_set(Evas_Object *obj, Elm_GLView_Func func); > > > void elm_glview_resize_func_set(Evas_Object *obj, Elm_GLView_Func func); > > > > > > resize callback can be controversial as well but I want to argue that > > > adding this callback > > > makes the render function a lot cleaner. To handle resize > > > differently, the user in > > > render function needs to manually compare and see if the size has > > changed, and > > > then handle the cases. Doing all of this internally once makes the > > > developers life > > > a lot easier in my opinion. > > > > > > these callback functions do make the render function a lot cleaner. > > > You can check > > > out the updated test_glview.c or newly added test_glview_simple. > > > > > > 2.) Minor bug fixes/changes > > > > > > elm_glview_scale_policy_set() was supposed to be > > elm_glview_resize_policy_set > > > () but it somehow evaded our reviews. That has been fixed. > > > > > > Also, in _glview_resize, after updating the surface, it was explicitly > > > calling the > > > render function. It is actually unnecessary here and calling it here > > > will cause > > > problems if resize gets called before everything else is setup > > > properly. So that has > > > been commented out. > > > > > > 3.) test_glview & test_glview_simple > > > > > > elementary_test case for glview has been updated to reflect the api > > changes. > > > when you run the elmentary_test, you need to make sure that you set
