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_Bool    elm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
Eina_Bool    elm_glview_scale_policy_set(Evas_Object *obj,
Elm_GLView_Resize_Policy policy);
Eina_Bool    elm_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 <ras...@rasterman.com> wrote:
>
> On Fri, 13 May 2011 00:00:50 +0900 "Sung W. Park" <sung...@gmail.com> 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_Bool        elm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode
> > mode); Eina_Bool        elm_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_Bool    elm_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
>

Attachment: elmglview.tgz
Description: GNU Zip compressed data

------------------------------------------------------------------------------
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
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to