[E-devel] [RFC] ELM GLView
Hi all,
As you all know, I've been working on adding GL rendering features to Evas and
we now have an early working version of Evas_GL in the svn.
Since then, there's been a request from people around me for an
elementary widget that
allows simple GL rendering. Since Evas_GL can be seen as a low level API it
made sense to have a user friendly layer that allows GL rendering. I
thought it
went well with the EFL philosophy. Take away some control but make it easy to
use for the users as you go up the layers from Evas->Ecore->ELM-> etc.
So, I've decided to take a crack at elm_glview. By the way, this is
my first time writing
an elementary widget so I KNOW I've missed a lot that i need to handle. Also,
I'm aware of the fact thatI need to handle input events. I'll need to
figure that out
but I open to comments and suggestions. However, before I get all the
nitty gritty
detail right, I wanted to start a discussion with the community on the APIs and
ask for suggestions.
So far, after discussing this with a few people, we've come up with
the following.
typedef enum _Elm_GLView_Scale_Policy
{
ELM_GLVIEW_POLICY_RESIZE, /**< Resize the internal surface
along with the image */
ELM_GLVIEW_POLICY_SCALE /**< Only reize the internal image
and not the surface */
} Elm_GLView_Scale_Policy;
Evas_Object *elm_glview_add(Evas_Object *parent);
void elm_glview_size_set(Evas_Object *obj, Evas_Coord
width, Evas_Coord height);
void elm_glview_size_get(Evas_Object *obj, Evas_Coord
*width, Evas_Coord *height);
Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
Elm_GLView_Scale_Policy policy);
void elm_glview_display_func(Evas_Object *obj,
Elm_GLView_Func func);
void elm_glview_changed_set(Evas_Object *obj);
Eina_Boolelm_glview_z_get(Evas_Object *obj, Evas_Coord x,
Evas_Coord y, Evas_Coord *z);
Internally, elm_glview handles creating an image object, evas_gl
object, evas_gl context,
surface, doing make current for display function. You just need to set
the display_function
callback and put your GL calls in there. The scale policy concerns how the
glview would resize. setting it to SCALE would keep the current
glview but simply scale
the underlying image. otherwise, it would recreate the surface. The
API is pretty straight forward
in my opinion. It's very much GLUT-like adapted for EFL.
In order to use the elm_glview, you would do something like
main()
{
...
// Add a GLView
glview = elm_glview_add(win);
glapi = elm_glview_gl_api_get(glview);
elm_glview_mode_set(glview, ELM_GLVIEW_ALPHA | ELM_GLVIEW_DEPTH);
elm_glview_scale_policy_set(glview, ELM_GLVIEW_POLICY_SCALE);
elm_glview_display_func(glview, (Elm_GLView_Func)draw);
evas_object_resize(glview, 256, 256);
evas_object_show(glview);
ecore_animator_add(on_animate, glview);
...
}
on_animate()
{
elm_glview_changed_set((Evas_Object*)data);
return EINA_TRUE;
}
// GL calls
draw()
{
elm_glview_size_get(..., &w, &h);
glapi->glViewport(..., w, h);
...
}
I guess it's easier to see the sample files and run the code to see
how they actually work.
I'm including a patch that shows the above example. I'm including the
following files.
1. elm_glview.path
-. apply using: patch -p0 elm_glview.patch
2. elm_glview.c
-. copy the file to src/lib
-. make/ install elmentary
3. elmglviewsample1.c, elmglviewgears.c, Makefile
-. do a make on the samples using the given makefile.
Ok, that's all for now. I'd love to hear comments and suggestions on
it as I continue to
work on it.
thanks!
cheers,
Sung
elmglview.tgz
Description: GNU Zip compressed data
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] ELM GLView
* Sung W. Park [2011-05-13 00:00:50 +0900]:
> Hi all,
>
> As you all know, I've been working on adding GL rendering features to Evas and
> we now have an early working version of Evas_GL in the svn.
>
> Since then, there's been a request from people around me for an
> elementary widget that
> allows simple GL rendering. Since Evas_GL can be seen as a low level API it
> made sense to have a user friendly layer that allows GL rendering. I
> thought it
> went well with the EFL philosophy. Take away some control but make it easy to
> use for the users as you go up the layers from Evas->Ecore->ELM-> etc.
>
> So, I've decided to take a crack at elm_glview. By the way, this is
> my first time writing
> an elementary widget so I KNOW I've missed a lot that i need to handle. Also,
> I'm aware of the fact thatI need to handle input events. I'll need to
> figure that out
> but I open to comments and suggestions. However, before I get all the
> nitty gritty
> detail right, I wanted to start a discussion with the community on the APIs
> and
> ask for suggestions.
>
> So far, after discussing this with a few people, we've come up with
> the following.
>
>typedef enum _Elm_GLView_Scale_Policy
> {
> ELM_GLVIEW_POLICY_RESIZE, /**< Resize the internal surface
> along with the image */
> ELM_GLVIEW_POLICY_SCALE /**< Only reize the internal image
> and not the surface */
> } Elm_GLView_Scale_Policy;
>
>Evas_Object *elm_glview_add(Evas_Object *parent);
>void elm_glview_size_set(Evas_Object *obj, Evas_Coord
> width, Evas_Coord height);
>void elm_glview_size_get(Evas_Object *obj, Evas_Coord
> *width, Evas_Coord *height);
>Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
>Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode
> mode);
>Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
> Elm_GLView_Scale_Policy policy);
>void elm_glview_display_func(Evas_Object *obj,
elm_glview_display_func_set would read more efl-ish, imo.
> Elm_GLView_Func func);
>void elm_glview_changed_set(Evas_Object *obj);
>Eina_Boolelm_glview_z_get(Evas_Object *obj, Evas_Coord x,
> Evas_Coord y, Evas_Coord *z);
>
>
> Internally, elm_glview handles creating an image object, evas_gl
> object, evas_gl context,
> surface, doing make current for display function. You just need to set
> the display_function
> callback and put your GL calls in there. The scale policy concerns how the
> glview would resize. setting it to SCALE would keep the current
> glview but simply scale
> the underlying image. otherwise, it would recreate the surface. The
> API is pretty straight forward
> in my opinion. It's very much GLUT-like adapted for EFL.
>
> In order to use the elm_glview, you would do something like
>
> main()
> {
>...
>// Add a GLView
>glview = elm_glview_add(win);
>glapi = elm_glview_gl_api_get(glview);
>elm_glview_mode_set(glview, ELM_GLVIEW_ALPHA | ELM_GLVIEW_DEPTH);
>elm_glview_scale_policy_set(glview, ELM_GLVIEW_POLICY_SCALE);
>elm_glview_display_func(glview, (Elm_GLView_Func)draw);
>evas_object_resize(glview, 256, 256);
>evas_object_show(glview);
>ecore_animator_add(on_animate, glview);
>...
> }
>
> on_animate()
> {
>elm_glview_changed_set((Evas_Object*)data);
>return EINA_TRUE;
> }
>
> // GL calls
> draw()
> {
>elm_glview_size_get(..., &w, &h);
>glapi->glViewport(..., w, h);
>...
> }
>
> I guess it's easier to see the sample files and run the code to see
> how they actually work.
> I'm including a patch that shows the above example. I'm including the
> following files.
>
> 1. elm_glview.path
> -. apply using: patch -p0 elm_glview.patch
> 2. elm_glview.c
> -. copy the file to src/lib
> -. make/ install elmentary
> 3. elmglviewsample1.c, elmglviewgears.c, Makefile
> -. do a make on the samples using the given makefile.
>
> Ok, that's all for now. I'd love to hear comments and suggestions on
> it as I continue to
> work on it.
>
> thanks!
>
> cheers,
> Sung
> --
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Gustavo Lima Chaves
Computer Engineer @ ProFUSION Embedded Systems
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach
Re: [E-devel] [RFC] ELM GLView
On Fri, 13 May 2011 00:00:50 +0900 "Sung W. Park" said:
ok. missing the focus hook thing u'd need if u want key events to work...
display_func -> render_func_set() probably better. z_get probably can be
skipped if really too much of a pita.
whats the gl_func_call api for.. why pass the func - u already set it? could
set it then call a manual render.. if that's needed. is it really needed?
curious. :)
> Hi all,
>
> As you all know, I've been working on adding GL rendering features to Evas and
> we now have an early working version of Evas_GL in the svn.
>
> Since then, there's been a request from people around me for an
> elementary widget that
> allows simple GL rendering. Since Evas_GL can be seen as a low level API it
> made sense to have a user friendly layer that allows GL rendering. I
> thought it
> went well with the EFL philosophy. Take away some control but make it easy to
> use for the users as you go up the layers from Evas->Ecore->ELM-> etc.
>
> So, I've decided to take a crack at elm_glview. By the way, this is
> my first time writing
> an elementary widget so I KNOW I've missed a lot that i need to handle. Also,
> I'm aware of the fact thatI need to handle input events. I'll need to
> figure that out
> but I open to comments and suggestions. However, before I get all the
> nitty gritty
> detail right, I wanted to start a discussion with the community on the APIs
> and ask for suggestions.
>
> So far, after discussing this with a few people, we've come up with
> the following.
>
>typedef enum _Elm_GLView_Scale_Policy
> {
> ELM_GLVIEW_POLICY_RESIZE, /**< Resize the internal surface
> along with the image */
> ELM_GLVIEW_POLICY_SCALE /**< Only reize the internal image
> and not the surface */
> } Elm_GLView_Scale_Policy;
>
>Evas_Object *elm_glview_add(Evas_Object *parent);
>void elm_glview_size_set(Evas_Object *obj, Evas_Coord
> width, Evas_Coord height);
>void elm_glview_size_get(Evas_Object *obj, Evas_Coord
> *width, Evas_Coord *height);
>Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
>Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode
> mode); Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
> Elm_GLView_Scale_Policy policy);
>void elm_glview_display_func(Evas_Object *obj,
> Elm_GLView_Func func);
>void elm_glview_changed_set(Evas_Object *obj);
>Eina_Boolelm_glview_z_get(Evas_Object *obj, Evas_Coord x,
> Evas_Coord y, Evas_Coord *z);
>
>
> Internally, elm_glview handles creating an image object, evas_gl
> object, evas_gl context,
> surface, doing make current for display function. You just need to set
> the display_function
> callback and put your GL calls in there. The scale policy concerns how the
> glview would resize. setting it to SCALE would keep the current
> glview but simply scale
> the underlying image. otherwise, it would recreate the surface. The
> API is pretty straight forward
> in my opinion. It's very much GLUT-like adapted for EFL.
>
> In order to use the elm_glview, you would do something like
>
> main()
> {
>...
>// Add a GLView
>glview = elm_glview_add(win);
>glapi = elm_glview_gl_api_get(glview);
>elm_glview_mode_set(glview, ELM_GLVIEW_ALPHA | ELM_GLVIEW_DEPTH);
>elm_glview_scale_policy_set(glview, ELM_GLVIEW_POLICY_SCALE);
>elm_glview_display_func(glview, (Elm_GLView_Func)draw);
>evas_object_resize(glview, 256, 256);
>evas_object_show(glview);
>ecore_animator_add(on_animate, glview);
>...
> }
>
> on_animate()
> {
>elm_glview_changed_set((Evas_Object*)data);
>return EINA_TRUE;
> }
>
> // GL calls
> draw()
> {
>elm_glview_size_get(..., &w, &h);
>glapi->glViewport(..., w, h);
>...
> }
>
> I guess it's easier to see the sample files and run the code to see
> how they actually work.
> I'm including a patch that shows the above example. I'm including the
> following files.
>
> 1. elm_glview.path
> -. apply using: patch -p0 elm_glview.patch
> 2. elm_glview.c
> -. copy the file to src/lib
> -. make/ install elmentary
> 3. elmglviewsample1.c, elmglviewgears.c, Makefile
> -. do a make on the samples using the given makefile.
>
> Ok, that's all for now. I'd love to hear comments and suggestions on
> it as I continue to
> work on it.
>
> thanks!
>
> cheers,
> Sung
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
enlighte
Re: [E-devel] [RFC] ELM GLView
Thanks for your comments.
Ok, I've added a focus_hook so it now handles events properly. Now
the elmglviewgears
handles key events and mouse events. You can rotate it using
"Left,Right,Up,Down Arrows"
or use the mouse and drag it. It doesn't actually have a real
trackball feature
implemented so you will notice it not rotating it properly if you
rotate it too much.
I've dropped the elm_glview_z_get function. I didn't think it was
necessary for now.
maybe we can add it later.
Also, the gl_func_call api was for internal testing purpose and it was
commented out
in the patch but i've removed them completely in this patch.
Also, I've made some changes with the API. It has been brought to my attention
that there is a performance issue with the way the current APIs are implemented.
Currently, the render function was registered using the
"evas_object_image_pixels_get_callback_set"
This is so that it doesn't trigger GL rendering when the image object
isn't visible.
Unfortunately, it causes and extra make_current to be called during
the rendering
life cycle of evas.
Evas Render... -> (context switch) -> EvasGL Renders -> (context_switch) -> Evas
Finishes rendering
The context switch is quite expensive in the hw driver that i'm using
so it actually
lowers the performance quite a bit.
SO, after discussing it with a few people, we've decided to give an
option to the user
to choose the rendering policy. If you choose to have render function
render all the time,
it avoids one extra context switch.
EvasGL Renders -> (context_switch) -> Evas Renders
Hence the render policy of RENDER_POLICY_ON_DEMAND vs. RENDER_POLICY_ALWAYS.
I've also changed the name "elm_glview_display_func" to "elm_glview_render_func"
Here's the latest set of elm_glview APIs...
__
typedef enum _Elm_GLView_Resize_Policy
{
ELM_GLVIEW_RESIZE_POLICY_RECREATE = 1,
ELM_GLVIEW_RESIZE_POLICY_SCALE= 2
} Elm_GLView_Resize_Policy;
typedef enum _Elm_GLView_Render_Policy
{
ELM_GLVIEW_RENDER_POLICY_ON_DEMAND = 1,
ELM_GLVIEW_RENDER_POLICY_ALWAYS= 2
} Elm_GLView_Render_Policy;
Evas_Object*elm_glview_add(Evas_Object *parent);
void elm_glview_size_set(Evas_Object *obj, Evas_Coord
width, Evas_Coord height);
void elm_glview_size_get(Evas_Object *obj, Evas_Coord
*width, Evas_Coord *height);
Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
Elm_GLView_Resize_Policy policy);
Eina_Boolelm_glview_render_policy_set(Evas_Object *obj,
Elm_GLView_Render_Policy policy);
void elm_glview_render_func(Evas_Object *obj, Elm_GLView_Func func);
void elm_glview_changed_set(Evas_Object *obj);
__
I'm including the updated elm_glview patch/files and the updated elmglviewgears.
Let me know if you have questions/comments.
cheers,
Sung
On Wed, May 18, 2011 at 7:10 PM, Carsten Haitzler wrote:
>
> On Fri, 13 May 2011 00:00:50 +0900 "Sung W. Park" said:
>
> ok. missing the focus hook thing u'd need if u want key events to work...
> display_func -> render_func_set() probably better. z_get probably can be
> skipped if really too much of a pita.
>
> whats the gl_func_call api for.. why pass the func - u already set it? could
> set it then call a manual render.. if that's needed. is it really needed?
> curious. :)
>
> > Hi all,
> >
> > As you all know, I've been working on adding GL rendering features to Evas
> > and
> > we now have an early working version of Evas_GL in the svn.
> >
> > Since then, there's been a request from people around me for an
> > elementary widget that
> > allows simple GL rendering. Since Evas_GL can be seen as a low level API it
> > made sense to have a user friendly layer that allows GL rendering. I
> > thought it
> > went well with the EFL philosophy. Take away some control but make it easy
> > to
> > use for the users as you go up the layers from Evas->Ecore->ELM-> etc.
> >
> > So, I've decided to take a crack at elm_glview. By the way, this is
> > my first time writing
> > an elementary widget so I KNOW I've missed a lot that i need to handle.
> > Also,
> > I'm aware of the fact thatI need to handle input events. I'll need to
> > figure that out
> > but I open to comments and suggestions. However, before I get all the
> > nitty gritty
> > detail right, I wanted to start a discussion with the community on the APIs
> > and ask for suggestions.
> >
> > So far, after discussing this with a few people, we've come up with
> > the following.
> >
> > typedef enum _Elm_GLView_Scale_Policy
> > {
> > ELM_GLVIEW_POLICY_RESIZE, /**< Resize the internal surface
> > along with the image */
> > ELM_GLVIEW_POLICY_SCALE /**< Only reize the internal image
> > and not the surface */
> > } Elm_GLView_Scale_Policy;
> >
> >
Re: [E-devel] [RFC] ELM GLView
On Thu, 19 May 2011 16:37:11 +0900 "Sung W. Park" said:
ok - started looking at this :) ummm...
3:58PM ~/elmglview > ELM_ENGINE=gl ./elmglviewgears
vertex shader info:
fragment shader info:
info:
ERR<28146>:evas-gl_x11 evas_engine.c:2582 eng_gl_make_current() xxxMakeCurrent
() failed!
?
> Thanks for your comments.
>
> Ok, I've added a focus_hook so it now handles events properly. Now
> the elmglviewgears
> handles key events and mouse events. You can rotate it using
> "Left,Right,Up,Down Arrows"
> or use the mouse and drag it. It doesn't actually have a real
> trackball feature
> implemented so you will notice it not rotating it properly if you
> rotate it too much.
>
> I've dropped the elm_glview_z_get function. I didn't think it was
> necessary for now.
> maybe we can add it later.
>
> Also, the gl_func_call api was for internal testing purpose and it was
> commented out
> in the patch but i've removed them completely in this patch.
>
> Also, I've made some changes with the API. It has been brought to my
> attention that there is a performance issue with the way the current APIs are
> implemented. Currently, the render function was registered using the
>
> "evas_object_image_pixels_get_callback_set"
>
> This is so that it doesn't trigger GL rendering when the image object
> isn't visible.
> Unfortunately, it causes and extra make_current to be called during
> the rendering
> life cycle of evas.
>
> Evas Render... -> (context switch) -> EvasGL Renders -> (context_switch) ->
> Evas Finishes rendering
>
> The context switch is quite expensive in the hw driver that i'm using
> so it actually
> lowers the performance quite a bit.
>
> SO, after discussing it with a few people, we've decided to give an
> option to the user
> to choose the rendering policy. If you choose to have render function
> render all the time,
> it avoids one extra context switch.
>
> EvasGL Renders -> (context_switch) -> Evas Renders
>
> Hence the render policy of RENDER_POLICY_ON_DEMAND vs. RENDER_POLICY_ALWAYS.
>
> I've also changed the name "elm_glview_display_func" to
> "elm_glview_render_func"
>
> Here's the latest set of elm_glview APIs...
> __
>
> typedef enum _Elm_GLView_Resize_Policy
> {
> ELM_GLVIEW_RESIZE_POLICY_RECREATE = 1,
> ELM_GLVIEW_RESIZE_POLICY_SCALE= 2
> } Elm_GLView_Resize_Policy;
>
> typedef enum _Elm_GLView_Render_Policy
> {
> ELM_GLVIEW_RENDER_POLICY_ON_DEMAND = 1,
> ELM_GLVIEW_RENDER_POLICY_ALWAYS= 2
> } Elm_GLView_Render_Policy;
>
>
> Evas_Object*elm_glview_add(Evas_Object *parent);
> void elm_glview_size_set(Evas_Object *obj, Evas_Coord
> width, Evas_Coord height);
> void elm_glview_size_get(Evas_Object *obj, Evas_Coord
> *width, Evas_Coord *height);
> Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
> Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
> Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
> Elm_GLView_Resize_Policy policy);
> Eina_Boolelm_glview_render_policy_set(Evas_Object *obj,
> Elm_GLView_Render_Policy policy);
> void elm_glview_render_func(Evas_Object *obj, Elm_GLView_Func
> func); void elm_glview_changed_set(Evas_Object *obj);
> __
>
> I'm including the updated elm_glview patch/files and the updated
> elmglviewgears.
>
> Let me know if you have questions/comments.
>
> cheers,
> Sung
>
>
> On Wed, May 18, 2011 at 7:10 PM, Carsten Haitzler
> wrote:
> >
> > On Fri, 13 May 2011 00:00:50 +0900 "Sung W. Park" said:
> >
> > ok. missing the focus hook thing u'd need if u want key events to work...
> > display_func -> render_func_set() probably better. z_get probably can be
> > skipped if really too much of a pita.
> >
> > whats the gl_func_call api for.. why pass the func - u already set it? could
> > set it then call a manual render.. if that's needed. is it really needed?
> > curious. :)
> >
> > > Hi all,
> > >
> > > As you all know, I've been working on adding GL rendering features to
> > > Evas and we now have an early working version of Evas_GL in the svn.
> > >
> > > Since then, there's been a request from people around me for an
> > > elementary widget that
> > > allows simple GL rendering. Since Evas_GL can be seen as a low level API
> > > it made sense to have a user friendly layer that allows GL rendering. I
> > > thought it
> > > went well with the EFL philosophy. Take away some control but make it
> > > easy to use for the users as you go up the layers from Evas->Ecore->ELM->
> > > etc.
> > >
> > > So, I've decided to take a crack at elm_glview. By the way, this is
> > > my first time writing
> > > an elementary widget so I KNOW I've missed a lot that i need to handle.
> > > Also, I'm aware of the fact thatI need to handle input events. I'll need
> > > to figure that out
> > > but I open to comments and suggestions. However, before I get
Re: [E-devel] [RFC] ELM GLView
On Thu, 19 May 2011 16:37:11 +0900 "Sung W. Park" said:
1. func_set for setting render func.. :)
2. fixes for size set for setting native buffer resolution/size - changing obj
size by a resize is not the way to go.
3. changes in policies were not enacted always. now they are.
4. a DEFAULT 64x64 buffer size :) so you have something at least as opposed to
0x0 :)
5. some other things...
also added my simple test case (i patched mine into elementary_test thus why
its created in a callback)
> Thanks for your comments.
>
> Ok, I've added a focus_hook so it now handles events properly. Now
> the elmglviewgears
> handles key events and mouse events. You can rotate it using
> "Left,Right,Up,Down Arrows"
> or use the mouse and drag it. It doesn't actually have a real
> trackball feature
> implemented so you will notice it not rotating it properly if you
> rotate it too much.
>
> I've dropped the elm_glview_z_get function. I didn't think it was
> necessary for now.
> maybe we can add it later.
>
> Also, the gl_func_call api was for internal testing purpose and it was
> commented out
> in the patch but i've removed them completely in this patch.
>
> Also, I've made some changes with the API. It has been brought to my
> attention that there is a performance issue with the way the current APIs are
> implemented. Currently, the render function was registered using the
>
> "evas_object_image_pixels_get_callback_set"
>
> This is so that it doesn't trigger GL rendering when the image object
> isn't visible.
> Unfortunately, it causes and extra make_current to be called during
> the rendering
> life cycle of evas.
>
> Evas Render... -> (context switch) -> EvasGL Renders -> (context_switch) ->
> Evas Finishes rendering
>
> The context switch is quite expensive in the hw driver that i'm using
> so it actually
> lowers the performance quite a bit.
>
> SO, after discussing it with a few people, we've decided to give an
> option to the user
> to choose the rendering policy. If you choose to have render function
> render all the time,
> it avoids one extra context switch.
>
> EvasGL Renders -> (context_switch) -> Evas Renders
>
> Hence the render policy of RENDER_POLICY_ON_DEMAND vs. RENDER_POLICY_ALWAYS.
>
> I've also changed the name "elm_glview_display_func" to
> "elm_glview_render_func"
>
> Here's the latest set of elm_glview APIs...
> __
>
> typedef enum _Elm_GLView_Resize_Policy
> {
> ELM_GLVIEW_RESIZE_POLICY_RECREATE = 1,
> ELM_GLVIEW_RESIZE_POLICY_SCALE= 2
> } Elm_GLView_Resize_Policy;
>
> typedef enum _Elm_GLView_Render_Policy
> {
> ELM_GLVIEW_RENDER_POLICY_ON_DEMAND = 1,
> ELM_GLVIEW_RENDER_POLICY_ALWAYS= 2
> } Elm_GLView_Render_Policy;
>
>
> Evas_Object*elm_glview_add(Evas_Object *parent);
> void elm_glview_size_set(Evas_Object *obj, Evas_Coord
> width, Evas_Coord height);
> void elm_glview_size_get(Evas_Object *obj, Evas_Coord
> *width, Evas_Coord *height);
> Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
> Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
> Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
> Elm_GLView_Resize_Policy policy);
> Eina_Boolelm_glview_render_policy_set(Evas_Object *obj,
> Elm_GLView_Render_Policy policy);
> void elm_glview_render_func(Evas_Object *obj, Elm_GLView_Func
> func); void elm_glview_changed_set(Evas_Object *obj);
> __
>
> I'm including the updated elm_glview patch/files and the updated
> elmglviewgears.
>
> Let me know if you have questions/comments.
>
> cheers,
> Sung
>
>
> On Wed, May 18, 2011 at 7:10 PM, Carsten Haitzler
> wrote:
> >
> > On Fri, 13 May 2011 00:00:50 +0900 "Sung W. Park" said:
> >
> > ok. missing the focus hook thing u'd need if u want key events to work...
> > display_func -> render_func_set() probably better. z_get probably can be
> > skipped if really too much of a pita.
> >
> > whats the gl_func_call api for.. why pass the func - u already set it? could
> > set it then call a manual render.. if that's needed. is it really needed?
> > curious. :)
> >
> > > Hi all,
> > >
> > > As you all know, I've been working on adding GL rendering features to
> > > Evas and we now have an early working version of Evas_GL in the svn.
> > >
> > > Since then, there's been a request from people around me for an
> > > elementary widget that
> > > allows simple GL rendering. Since Evas_GL can be seen as a low level API
> > > it made sense to have a user friendly layer that allows GL rendering. I
> > > thought it
> > > went well with the EFL philosophy. Take away some control but make it
> > > easy to use for the users as you go up the layers from Evas->Ecore->ELM->
> > > etc.
> > >
> > > So, I've decided to take a crack at elm_glview. By the way, this is
> > > my first time writing
> > > an elementary widget so I KNOW I've missed a lot t
Re: [E-devel] [RFC] ELM GLView
On Thu, 19 May 2011 16:37:11 +0900 "Sung W. Park" said:
just put it in svn now. yay! :) thanks! :)
> Thanks for your comments.
>
> Ok, I've added a focus_hook so it now handles events properly. Now
> the elmglviewgears
> handles key events and mouse events. You can rotate it using
> "Left,Right,Up,Down Arrows"
> or use the mouse and drag it. It doesn't actually have a real
> trackball feature
> implemented so you will notice it not rotating it properly if you
> rotate it too much.
>
> I've dropped the elm_glview_z_get function. I didn't think it was
> necessary for now.
> maybe we can add it later.
>
> Also, the gl_func_call api was for internal testing purpose and it was
> commented out
> in the patch but i've removed them completely in this patch.
>
> Also, I've made some changes with the API. It has been brought to my
> attention that there is a performance issue with the way the current APIs are
> implemented. Currently, the render function was registered using the
>
> "evas_object_image_pixels_get_callback_set"
>
> This is so that it doesn't trigger GL rendering when the image object
> isn't visible.
> Unfortunately, it causes and extra make_current to be called during
> the rendering
> life cycle of evas.
>
> Evas Render... -> (context switch) -> EvasGL Renders -> (context_switch) ->
> Evas Finishes rendering
>
> The context switch is quite expensive in the hw driver that i'm using
> so it actually
> lowers the performance quite a bit.
>
> SO, after discussing it with a few people, we've decided to give an
> option to the user
> to choose the rendering policy. If you choose to have render function
> render all the time,
> it avoids one extra context switch.
>
> EvasGL Renders -> (context_switch) -> Evas Renders
>
> Hence the render policy of RENDER_POLICY_ON_DEMAND vs. RENDER_POLICY_ALWAYS.
>
> I've also changed the name "elm_glview_display_func" to
> "elm_glview_render_func"
>
> Here's the latest set of elm_glview APIs...
> __
>
> typedef enum _Elm_GLView_Resize_Policy
> {
> ELM_GLVIEW_RESIZE_POLICY_RECREATE = 1,
> ELM_GLVIEW_RESIZE_POLICY_SCALE= 2
> } Elm_GLView_Resize_Policy;
>
> typedef enum _Elm_GLView_Render_Policy
> {
> ELM_GLVIEW_RENDER_POLICY_ON_DEMAND = 1,
> ELM_GLVIEW_RENDER_POLICY_ALWAYS= 2
> } Elm_GLView_Render_Policy;
>
>
> Evas_Object*elm_glview_add(Evas_Object *parent);
> void elm_glview_size_set(Evas_Object *obj, Evas_Coord
> width, Evas_Coord height);
> void elm_glview_size_get(Evas_Object *obj, Evas_Coord
> *width, Evas_Coord *height);
> Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
> Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
> Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
> Elm_GLView_Resize_Policy policy);
> Eina_Boolelm_glview_render_policy_set(Evas_Object *obj,
> Elm_GLView_Render_Policy policy);
> void elm_glview_render_func(Evas_Object *obj, Elm_GLView_Func
> func); void elm_glview_changed_set(Evas_Object *obj);
> __
>
> I'm including the updated elm_glview patch/files and the updated
> elmglviewgears.
>
> Let me know if you have questions/comments.
>
> cheers,
> Sung
>
>
> On Wed, May 18, 2011 at 7:10 PM, Carsten Haitzler
> wrote:
> >
> > On Fri, 13 May 2011 00:00:50 +0900 "Sung W. Park" said:
> >
> > ok. missing the focus hook thing u'd need if u want key events to work...
> > display_func -> render_func_set() probably better. z_get probably can be
> > skipped if really too much of a pita.
> >
> > whats the gl_func_call api for.. why pass the func - u already set it? could
> > set it then call a manual render.. if that's needed. is it really needed?
> > curious. :)
> >
> > > Hi all,
> > >
> > > As you all know, I've been working on adding GL rendering features to
> > > Evas and we now have an early working version of Evas_GL in the svn.
> > >
> > > Since then, there's been a request from people around me for an
> > > elementary widget that
> > > allows simple GL rendering. Since Evas_GL can be seen as a low level API
> > > it made sense to have a user friendly layer that allows GL rendering. I
> > > thought it
> > > went well with the EFL philosophy. Take away some control but make it
> > > easy to use for the users as you go up the layers from Evas->Ecore->ELM->
> > > etc.
> > >
> > > So, I've decided to take a crack at elm_glview. By the way, this is
> > > my first time writing
> > > an elementary widget so I KNOW I've missed a lot that i need to handle.
> > > Also, I'm aware of the fact thatI need to handle input events. I'll need
> > > to figure that out
> > > but I open to comments and suggestions. However, before I get all the
> > > nitty gritty
> > > detail right, I wanted to start a discussion with the community on the
> > > APIs and ask for suggestions.
> > >
> > > So far, after discussing this with a few peopl
Re: [E-devel] [RFC] ELM GLView
awesome! I guess we now have to make sure this thing is stable. =)
On Fri, Jun 3, 2011 at 4:09 PM, Carsten Haitzler wrote:
> On Thu, 19 May 2011 16:37:11 +0900 "Sung W. Park"
> said:
>
> just put it in svn now. yay! :) thanks! :)
>
> > Thanks for your comments.
> >
> > Ok, I've added a focus_hook so it now handles events properly. Now
> > the elmglviewgears
> > handles key events and mouse events. You can rotate it using
> > "Left,Right,Up,Down Arrows"
> > or use the mouse and drag it. It doesn't actually have a real
> > trackball feature
> > implemented so you will notice it not rotating it properly if you
> > rotate it too much.
> >
> > I've dropped the elm_glview_z_get function. I didn't think it was
> > necessary for now.
> > maybe we can add it later.
> >
> > Also, the gl_func_call api was for internal testing purpose and it was
> > commented out
> > in the patch but i've removed them completely in this patch.
> >
> > Also, I've made some changes with the API. It has been brought to my
> > attention that there is a performance issue with the way the current APIs
> are
> > implemented. Currently, the render function was registered using the
> >
> > "evas_object_image_pixels_get_callback_set"
> >
> > This is so that it doesn't trigger GL rendering when the image object
> > isn't visible.
> > Unfortunately, it causes and extra make_current to be called during
> > the rendering
> > life cycle of evas.
> >
> > Evas Render... -> (context switch) -> EvasGL Renders -> (context_switch)
> ->
> > Evas Finishes rendering
> >
> > The context switch is quite expensive in the hw driver that i'm using
> > so it actually
> > lowers the performance quite a bit.
> >
> > SO, after discussing it with a few people, we've decided to give an
> > option to the user
> > to choose the rendering policy. If you choose to have render function
> > render all the time,
> > it avoids one extra context switch.
> >
> > EvasGL Renders -> (context_switch) -> Evas Renders
> >
> > Hence the render policy of RENDER_POLICY_ON_DEMAND vs.
> RENDER_POLICY_ALWAYS.
> >
> > I've also changed the name "elm_glview_display_func" to
> > "elm_glview_render_func"
> >
> > Here's the latest set of elm_glview APIs...
> > __
> >
> > typedef enum _Elm_GLView_Resize_Policy
> > {
> > ELM_GLVIEW_RESIZE_POLICY_RECREATE = 1,
> > ELM_GLVIEW_RESIZE_POLICY_SCALE= 2
> > } Elm_GLView_Resize_Policy;
> >
> > typedef enum _Elm_GLView_Render_Policy
> > {
> > ELM_GLVIEW_RENDER_POLICY_ON_DEMAND = 1,
> > ELM_GLVIEW_RENDER_POLICY_ALWAYS= 2
> > } Elm_GLView_Render_Policy;
> >
> >
> > Evas_Object*elm_glview_add(Evas_Object *parent);
> > void elm_glview_size_set(Evas_Object *obj, Evas_Coord
> > width, Evas_Coord height);
> > void elm_glview_size_get(Evas_Object *obj, Evas_Coord
> > *width, Evas_Coord *height);
> > Evas_GL_API *elm_glview_gl_api_get(Evas_Object *obj);
> > Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
> > Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
> > Elm_GLView_Resize_Policy policy);
> > Eina_Boolelm_glview_render_policy_set(Evas_Object *obj,
> > Elm_GLView_Render_Policy policy);
> > void elm_glview_render_func(Evas_Object *obj, Elm_GLView_Func
> > func); void elm_glview_changed_set(Evas_Object *obj);
> > __
> >
> > I'm including the updated elm_glview patch/files and the updated
> > elmglviewgears.
> >
> > Let me know if you have questions/comments.
> >
> > cheers,
> > Sung
> >
> >
> > On Wed, May 18, 2011 at 7:10 PM, Carsten Haitzler
> > wrote:
> > >
> > > On Fri, 13 May 2011 00:00:50 +0900 "Sung W. Park"
> said:
> > >
> > > ok. missing the focus hook thing u'd need if u want key events to
> work...
> > > display_func -> render_func_set() probably better. z_get probably can
> be
> > > skipped if really too much of a pita.
> > >
> > > whats the gl_func_call api for.. why pass the func - u already set it?
> could
> > > set it then call a manual render.. if that's needed. is it really
> needed?
> > > curious. :)
> > >
> > > > Hi all,
> > > >
> > > > As you all know, I've been working on adding GL rendering features to
> > > > Evas and we now have an early working version of Evas_GL in the svn.
> > > >
> > > > Since then, there's been a request from people around me for an
> > > > elementary widget that
> > > > allows simple GL rendering. Since Evas_GL can be seen as a low level
> API
> > > > it made sense to have a user friendly layer that allows GL rendering.
> I
> > > > thought it
> > > > went well with the EFL philosophy. Take away some control but make
> it
> > > > easy to use for the users as you go up the layers from
> Evas->Ecore->ELM->
> > > > etc.
> > > >
> > > > So, I've decided to take a crack at elm_glview. By the way, this is
> > > > my first time writing
> > > > an elementary widget so I KNOW I've missed a lot that i need to
