[E-devel] new evas compile warnings

[Sung W. Park]

Hi Mike,

Thanks for pointing out those warnings.  I will get on them as soon as I
get back.
I've been traveling for the past two weeks and I won't be back until
Monday.
They really should not have gotten in there in the first place.

Evas_GL has been getting really messy over the past year with workarounds,
optimizations, and bug fixes so I am actually in the process of rewriting
them so that the
common code can be shared among different engines: ie. wayland and gl_x11.

It'll be a lot cleaner for sure.

thanks.
Sung


On Saturday, August 18, 2012, Michael Blumenkrantz wrote:

> Making all in gl_common
>   CC   evas_gl_context.lo
>   CC   evas_gl_shader.lo
>   CC   evas_gl_rectangle.lo
>   CC   evas_gl_texture.lo
>   CC   evas_gl_image.lo
>   CC   evas_gl_font.lo
>   CC   evas_gl_polygon.lo
>   CC   evas_gl_line.lo
>   CC   evas_gl_filter.lo
> evas_gl_texture.c: In function '_tex_2d':
> evas_gl_texture.c:119:8: warning: the address of 'glGetTexLevelParameteriv'
> will always evaluate as 'true' CCLD libevas_engine_gl_common.la
> Making all in gl_x11
>   CC   module_la-evas_engine.lo
>   CC   module_la-evas_x_main.lo
> evas_engine.c: In function '_gl_ext_sym_init':
> evas_engine.c:542:115: warning: assignment from incompatible pointer type
> evas_engine.c:542:273: warning: assignment from incompatible pointer type
> evas_engine.c: In function 'eng_image_map_clean':
> evas_engine.c:2836:27: warning: unused parameter 'data'
> evas_engine.c:2836:43: warning: unused parameter 'm'
> evas_engine.c: In function '_print_gl_surface_info':
> evas_engine.c:3067:137: warning: cast from pointer to integer of different
> size
> evas_engine.c:3067:284: warning: cast from pointer to integer of different
> size
> evas_engine.c:3071:148: warning: cast from pointer to integer of different
> size
> evas_engine.c:3071:319: warning: cast from pointer to integer of different
> size
> evas_engine.c: In function '_set_gl_surface_cap':
> evas_engine.c:3131:28: warning: unused variable 'stencil'
> evas_engine.c:3131:21: warning: unused variable 'depth'
> evas_engine.c:3131:16: warning: unused variable 'tex'
> evas_engine.c:3131:11: warning: unused variable 'fbo'
> evas_engine.c: In function '_set_internal_config':
> evas_engine.c:3315:33: warning: comparison between signed and unsigned
> integer
> expressions evas_engine.c:3316:33: warning: comparison between signed and
> unsigned integer expressions evas_engine.c: In function
> '_create_rt_buffers':
> evas_engine.c:3557:4: warning: pointer targets in passing argument 2 of
> 'glGetIntegerv' differ in signedness /usr/include/GL/gl.h:842:45: note:
> expected 'GLint *' but argument is of type 'GLuint *' evas_engine.c: In
> function 'eng_gl_surface_create': evas_engine.c:3588:31: warning: unused
> variable 'rsc' evas_engine.c: In function 'eng_gl_surface_destroy':
> evas_engine.c:3682:31: warning: unused variable 'rsc'
> evas_engine.c: In function 'eng_gl_context_destroy':
> evas_engine.c:3827:31: warning: unused variable 'rsc'
> evas_engine.c: In function 'eng_gl_make_current':
> evas_engine.c:3969:30: warning: comparison between signed and unsigned
> integer
> expressions evas_engine.c: In function 'evgl_glGetShaderPrecisionFormat':
> evas_engine.c:4415:40: warning: unused parameter 'shadertype'
> evas_engine.c:4415:59: warning: unused parameter 'precisiontype'
>   CCLD module.la
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas_GL Refactored Code

[Sung W. Park]

Hi Chris,

Thanks for the fast review. :)

On Tue, Sep 18, 2012 at 4:17 PM, Christopher Michael  wrote:

> Hi Sung,
>
> Initial review of this:
>
> Short version, it looks good :) but found some problems in you're patch:
>
> In the evgl_eng_window_surface_create for the GLES_VARIETY_SGX path:
>
> +   surface = eglCreateWindowSurface(re->**win->egl_disp,
> +re->win->egl_config,
> + (EGLNativeWindowType)**DefaultRootWindow(re->info->**info.display),
> +NULL);
>
> DefaultRootWindow is an X11 function. This will fail for wayland_egl.
> Better to use re->win->win here IMO.
>

I can fix that easily. I can't remember why I did it this way to tell you
the truth.


>
> Also, I noticed in some places that we are still using
> glsym_eglQueryString and glXQueryString. Wouldn't it be better if Evas_GL
> provided a QueryString function ? This way the various backends could call
> which ever querystring function they use ? (Same for GetProcAddress).
> Basically, the EVGL_Interface could provide 2 more methods. QueryString and
> GetProcAddress.
>

What do you mean by some places? In evas_engine? or evas_gl_core?

I actually tried to remove all the EGL/GLX dependencies from the Evas_GL
part of the code.  That way, evas_engine can handle with the glue layer
stuff and evas_gl_core would only need to handle with GL. That's the reason
why evas_engine has to provide these two functions to evas_gl_core.  It's
part of the engine interface.

Maybe I misunderstood you?


>
> Other than that, I Like It :) It removes a lot of duplicated code and is
> good (in general).
>
> I agree.  I like it a lot better as well (in general) ;-)


> Cheers,
> dh
>
>
I'll wait for Carsten to take a look at it as well and then push it up.

Thanks!
Sung


>
> On 17/09/12 10:52, Sung W. Park wrote:
>
>> Hi all,
>>
>> I'd like to ask you devs for review on Evas_GL that I've recently
>> refactored
>> before I push it upstream.
>>
>> evas_gl was introduced last year and it has gotten really messy over the
>> year
>> with a lot of little tweaks here and there.
>>
>> Also, I've noticed not too long ago that the same code was pretty much
>> being
>> copied over to wayland_egl engine and so I've decided that it's about time
>> to
>> rewrite the ugly code.
>>
>> I've commonized the GL part of the code and made an interface that
>> each engine has to implement to get the evas_gl running.  In the overall
>> scheme of things, one can argue whether this was the best design but with
>> what we have currently, i thought it was reasonable.
>>
>> I'm attaching a patch that modifies the following files...
>>
>> src/modules/engines/gl_common/**Makefile.am
>> src/modules/engines/gl_x11/**evas_engine.c
>>
>> and I've added 7 new files in gl_common.
>>
>> src/modules/engines/gl_common/**evas_gl_core_private.h
>> src/modules/engines/gl_common/**evas_gl_core.h
>> src/modules/engines/gl_common/**evas_gl_core.c
>> src/modules/engines/gl_common/**evas_gl_api.c
>> src/modules/engines/gl_common/**evas_gl_api_ext_def.h
>> src/modules/engines/gl_common/**evas_gl_api_ext.h
>> src/modules/engines/gl_common/**evas_gl_api_ext.c
>>
>> I'm also including two samples files as well as a PPT slides I've
>> made for some people here.
>>
>> Your comments would be greatly appreciated.
>>
>> cheers,
>> Sung
>>
>>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas_GL Refactored Code

[Sung W. Park]

On Tue, Sep 18, 2012 at 8:21 PM, Carsten Haitzler wrote:

> On Mon, 17 Sep 2012 18:52:06 +0900 "Sung W. Park" 
> said:
>
> you might want to check your compile warnings. :) like...
>
> evas_engine.c:2620:1: warning: no return statement in function returning
> non-void
>

yeah, I caught this afterwards. :)



>
> :) other fun like unused parameters in evas_gl_api.c ...
>
>
actually, I did run the compiler flag with all the warnings on and some of
the variables come as unused because they're only used on target (with the
#ifdef GLES_VARIETY_...).  Any thoughts or suggestions on this?


> hint:
>
> export CFLAGS="-W -Wall -Wextra"
>
> :)
>
>
> and yes even tho the eglCreateWindowSurface() using root is not portable to
> wayland. it is in gl_x11 which means its bound to x11. so thats ok. i
> don't see
> what else could have been done. if the egl/glx stuff was virtualized to be
> shared then yes - it'd be a problem. :)
>
> evas_engine.c has lost like 2000 lines of code. that's good! :)
>
> i say put it in and clean up the nigglies (formatting etc.) then live. :)
>

will do.  thanks~!


>
> > Hi all,
> >
> > I'd like to ask you devs for review on Evas_GL that I've recently
> refactored
> > before I push it upstream.
> >
> > evas_gl was introduced last year and it has gotten really messy over the
> > year
> > with a lot of little tweaks here and there.
> >
> > Also, I've noticed not too long ago that the same code was pretty much
> > being
> > copied over to wayland_egl engine and so I've decided that it's about
> time
> > to
> > rewrite the ugly code.
> >
> > I've commonized the GL part of the code and made an interface that
> > each engine has to implement to get the evas_gl running.  In the overall
> > scheme of things, one can argue whether this was the best design but with
> > what we have currently, i thought it was reasonable.
> >
> > I'm attaching a patch that modifies the following files...
> >
> > src/modules/engines/gl_common/Makefile.am
> > src/modules/engines/gl_x11/evas_engine.c
> >
> > and I've added 7 new files in gl_common.
> >
> > src/modules/engines/gl_common/evas_gl_core_private.h
> > src/modules/engines/gl_common/evas_gl_core.h
> > src/modules/engines/gl_common/evas_gl_core.c
> > src/modules/engines/gl_common/evas_gl_api.c
> > src/modules/engines/gl_common/evas_gl_api_ext_def.h
> > src/modules/engines/gl_common/evas_gl_api_ext.h
> > src/modules/engines/gl_common/evas_gl_api_ext.c
> >
> > I'm also including two samples files as well as a PPT slides I've
> > made for some people here.
> >
> > Your comments would be greatly appreciated.
> >
> > cheers,
> > Sung
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas_GL Refactored Code

[Sung W. Park]

On Tue, Sep 18, 2012 at 9:14 PM, Christopher Michael  wrote:

> On 18/09/12 12:21, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 17 Sep 2012 18:52:06 +0900 "Sung W. Park" 
> said:
> >
> > you might want to check your compile warnings. :) like...
> >
> > evas_engine.c:2620:1: warning: no return statement in function returning
> > non-void
> >
> > :) other fun like unused parameters in evas_gl_api.c ...
> >
> > hint:
> >
> > export CFLAGS="-W -Wall -Wextra"
> >
> > :)
> >
> >
> > and yes even tho the eglCreateWindowSurface() using root is not portable
> to
> > wayland. it is in gl_x11 which means its bound to x11. so thats ok. i
> don't see
> > what else could have been done. if the egl/glx stuff was virtualized to
> be
> > shared then yes - it'd be a problem. :)
>
> I was under the impression that the patch was to address virtualization
> to reduce duplicated code...



I guess maybe I wasn't completely clear.

Yes, I am handling the duplicate code.  What I have done is separate all
the GL code with EGL/GLX (platform dependent) code.  All the GL code is
implemented in gl_common/ under evas_gl_core and etc. and the platform
dependent parts are implemented in evas_engine.c as engine functions.   So,
for waylaind_egl engine, you'd have to implement those parts, although
technically you can copy and paste the egl part from gl_x11 engine with a
few minor tweaks.  At least this will get rid of 2000 lines of duplicate
code in evas_engine. :-) I can help you try to port it over to wayland_egl
engine.. although I won't be able to test it.

Let me know if you questions.
Sung



> dh
>
> >
> > evas_engine.c has lost like 2000 lines of code. that's good! :)
> >
> > i say put it in and clean up the nigglies (formatting etc.) then live. :)
> >
> >> Hi all,
> >>
> >> I'd like to ask you devs for review on Evas_GL that I've recently
> refactored
> >> before I push it upstream.
> >>
> >> evas_gl was introduced last year and it has gotten really messy over the
> >> year
> >> with a lot of little tweaks here and there.
> >>
> >> Also, I've noticed not too long ago that the same code was pretty much
> >> being
> >> copied over to wayland_egl engine and so I've decided that it's about
> time
> >> to
> >> rewrite the ugly code.
> >>
> >> I've commonized the GL part of the code and made an interface that
> >> each engine has to implement to get the evas_gl running.  In the overall
> >> scheme of things, one can argue whether this was the best design but
> with
> >> what we have currently, i thought it was reasonable.
> >>
> >> I'm attaching a patch that modifies the following files...
> >>
> >> src/modules/engines/gl_common/Makefile.am
> >> src/modules/engines/gl_x11/evas_engine.c
> >>
> >> and I've added 7 new files in gl_common.
> >>
> >> src/modules/engines/gl_common/evas_gl_core_private.h
> >> src/modules/engines/gl_common/evas_gl_core.h
> >> src/modules/engines/gl_common/evas_gl_core.c
> >> src/modules/engines/gl_common/evas_gl_api.c
> >> src/modules/engines/gl_common/evas_gl_api_ext_def.h
> >> src/modules/engines/gl_common/evas_gl_api_ext.h
> >> src/modules/engines/gl_common/evas_gl_api_ext.c
> >>
> >> I'm also including two samples files as well as a PPT slides I've
> >> made for some people here.
> >>
> >> Your comments would be greatly appreciated.
> >>
> >> cheers,
> >> Sung
> >
> >
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e] evas bad typedef

[Sung W. Park]

I'll look into it and fix it.

thanks.
Sung

On Fri, Oct 5, 2012 at 5:02 AM, rustyBSD  wrote:

> Le 01/10/2012 19:08, rustyBSD a écrit :
> > Hi,
> > == evas_gl_api_ext.h l.4 ==
> > The GLchar type is already defined on openbsd
> > (/usr/X11R6/include/GL/glext.h), so it has to
> > be renamed.
>
> You should really use another name.GLchar
> already comes with gl/opengl.
>
> OpenBSD and NetBSD don't like that.
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e] evas bad typedef

[Sung W. Park]

It wasn't needed so I removed it.  I can't remember why it was left in
there first place.

thanks for letting me know!

cheers,
Sung

On Fri, Oct 5, 2012 at 2:32 PM, Sung W. Park  wrote:

> I'll look into it and fix it.
>
> thanks.
> Sung
>
>
> On Fri, Oct 5, 2012 at 5:02 AM, rustyBSD  wrote:
>
>> Le 01/10/2012 19:08, rustyBSD a écrit :
>> > Hi,
>> > == evas_gl_api_ext.h l.4 ==
>> > The GLchar type is already defined on openbsd
>> > (/usr/X11R6/include/GL/glext.h), so it has to
>> > be renamed.
>>
>> You should really use another name.GLchar
>> already comes with gl/opengl.
>>
>> OpenBSD and NetBSD don't like that.
>>
>> --
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: sung IN trunk/efl: . src src/modules/evas/engines/gl_common

[Sung W. Park]

Leadro,

yes, they need to be invalidated.  The times that it would really matter is
when your GL driver is updated with some new fbo surface features or if you
change GPUs entirely, hence changing drivers.  I'm thinking about adding GL
driver name/version as a means to invalidate them.  Let me know if you have
other suggestions.

Daniel,

All I did with the shader stuff was to take the functions out so I can
share them.  I know that evas_gl isn't used in E so I would be surprised to
find out that it would cause crashes... plush my E was running fine when I
applied the changes but i'll have to take a look.

cheers,
Sung




On Mon, Jan 7, 2013 at 9:33 PM, Daniel Juyung Seo wrote:

> Maybe.. is this the reason why I got e17 crashes on shader stuff?
> It crashed a lot today.
>
> #27 0xb36121a9 in shader_array_flush (gc=0xa189950)
> at modules/evas/engines/gl_common/evas_gl_context.c:2774
> texuv_ptr = 0xf000 
> texuv3_ptr = 0x27000 
> vertex_ptr = 
> color_ptr = 0x9000 
> texuv2_ptr = 0x1b000 
> texm_ptr = 0x33000 
> i = 
> gw = 1680
> cy = 
> fbo = 0
> done = 1
> gh = 1050
> setclip = 
>
> You can find full crash dump from here.
> http://www.enlightenment.org/~seoz/e-crashdump.txt
>
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
> On Mon, Jan 7, 2013 at 9:12 PM, Leandro Dorileo  >wrote:
>
> > Hi,
> >
> > On Sun, Jan 06, 2013 at 10:16:18PM -0800, Enlightenment SVN wrote:
> > > Log:
> > > Pulled out evas gl backend binary shader file caching code from
> > >   evas_gl_shader.c file and made an internal generic caching api in
> > >   evas_gl_common.h for use in other places ie. evas_gl.
> > >
> > >   Then implemented evas_gl surface cap. caching code in gl backend to
> > >   accelerate the engine creation.
> > >
> > >
> > >
> > > Author:   sung
> > > Date: 2013-01-06 22:16:18 -0800 (Sun, 06 Jan 2013)
> > > New Revision: 82321
> > > Trac: http://trac.enlightenment.org/e/changeset/82321
> > >
> > > Added:
> > >   trunk/efl/src/modules/evas/engines/gl_common/evas_gl_file_cache.c
> > > Modified:
> > >   trunk/efl/ChangeLog trunk/efl/src/Makefile_Evas.am
> > trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
> > trunk/efl/src/modules/evas/engines/gl_common/evas_gl_core.c
> > trunk/efl/src/modules/evas/engines/gl_common/evas_gl_shader.c
> > >
> > > Modified: trunk/efl/ChangeLog
> > > ===
> > > --- trunk/efl/ChangeLog   2013-01-07 06:06:16 UTC (rev 82320)
> > > +++ trunk/efl/ChangeLog   2013-01-07 06:16:18 UTC (rev 82321)
> > > @@ -1,3 +1,12 @@
> > > +2013-01-07 Sung W. Park (sung_)
> > > +
> > > + * Pulled out evas gl backend binary shader file caching code from
> > > +evas_gl_shader.c file and made an internal generic caching api
> > in
> > > +evas_gl_common.h for use in evas_gl code.
> > > +* Implemented evas_gl surface cap. caching code in gl backend
> to
> > > +accelerate the engine creation.
> > > +
> > > +
> > >  2013-01-07  Thomas Petazzoni
> > >
> > >   * Fix build of Evas XCB backend.
> > >
> > > Modified: trunk/efl/src/Makefile_Evas.am
> > > ===
> > > --- trunk/efl/src/Makefile_Evas.am2013-01-07 06:06:16 UTC (rev
> 82320)
> > > +++ trunk/efl/src/Makefile_Evas.am2013-01-07 06:16:18 UTC (rev
> 82321)
> > > @@ -448,6 +448,7 @@
> > >  modules/evas/engines/gl_common/evas_gl_private.h \
> > >  modules/evas/engines/gl_common/evas_gl_common.h \
> > >  modules/evas/engines/gl_common/evas_gl_context.c \
> > > +modules/evas/engines/gl_common/evas_gl_file_cache.c \
> > >  modules/evas/engines/gl_common/evas_gl_shader.c \
> > >  modules/evas/engines/gl_common/evas_gl_rectangle.c \
> > >  modules/evas/engines/gl_common/evas_gl_texture.c \
> > >
> > > Modified: trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
> > > ===
> > > --- trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
> > 2013-01-07 06:06:16 UTC (rev 82320)
> > > +++ trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
> > 2013-01-07 06:16:18 UTC (rev 82321)
> > > @@ -555,6 +555,15 @

Re: [E-devel] E SVN: sung IN trunk/efl: . src src/modules/evas/engines/gl_common

[Sung W. Park]

Leandro,

nevermind the last comment.   It creates a new file based on the driver
already so it shouldn't have issues with new drivers and gpus.  It's
basically using the same mechanism as the binary shader so it should be
fine.  i got confused for a sec.

thanks for pointing it out though.

cheers,
Sung

On Tue, Jan 8, 2013 at 9:53 AM, Sung W. Park  wrote:

> Leadro,
>
> yes, they need to be invalidated.  The times that it would really matter
> is when your GL driver is updated with some new fbo surface features or if
> you change GPUs entirely, hence changing drivers.  I'm thinking about
> adding GL driver name/version as a means to invalidate them.  Let me know
> if you have other suggestions.
>
> Daniel,
>
> All I did with the shader stuff was to take the functions out so I can
> share them.  I know that evas_gl isn't used in E so I would be surprised to
> find out that it would cause crashes... plush my E was running fine when I
> applied the changes but i'll have to take a look.
>
> cheers,
> Sung
>
>
>
>
> On Mon, Jan 7, 2013 at 9:33 PM, Daniel Juyung Seo wrote:
>
>> Maybe.. is this the reason why I got e17 crashes on shader stuff?
>> It crashed a lot today.
>>
>> #27 0xb36121a9 in shader_array_flush (gc=0xa189950)
>> at modules/evas/engines/gl_common/evas_gl_context.c:2774
>> texuv_ptr = 0xf000 
>> texuv3_ptr = 0x27000 
>> vertex_ptr = 
>> color_ptr = 0x9000 
>> texuv2_ptr = 0x1b000 
>> texm_ptr = 0x33000 
>> i = 
>> gw = 1680
>> cy = 
>> fbo = 0
>> done = 1
>> gh = 1050
>> setclip = 
>>
>> You can find full crash dump from here.
>> http://www.enlightenment.org/~seoz/e-crashdump.txt
>>
>> Thanks.
>>
>> Daniel Juyung Seo (SeoZ)
>>
>> On Mon, Jan 7, 2013 at 9:12 PM, Leandro Dorileo > >wrote:
>>
>> > Hi,
>> >
>> > On Sun, Jan 06, 2013 at 10:16:18PM -0800, Enlightenment SVN wrote:
>> > > Log:
>> > > Pulled out evas gl backend binary shader file caching code from
>> > >   evas_gl_shader.c file and made an internal generic caching api in
>> > >   evas_gl_common.h for use in other places ie. evas_gl.
>> > >
>> > >   Then implemented evas_gl surface cap. caching code in gl backend to
>> > >   accelerate the engine creation.
>> > >
>> > >
>> > >
>> > > Author:   sung
>> > > Date: 2013-01-06 22:16:18 -0800 (Sun, 06 Jan 2013)
>> > > New Revision: 82321
>> > > Trac: http://trac.enlightenment.org/e/changeset/82321
>> > >
>> > > Added:
>> > >   trunk/efl/src/modules/evas/engines/gl_common/evas_gl_file_cache.c
>> > > Modified:
>> > >   trunk/efl/ChangeLog trunk/efl/src/Makefile_Evas.am
>> > trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
>> > trunk/efl/src/modules/evas/engines/gl_common/evas_gl_core.c
>> > trunk/efl/src/modules/evas/engines/gl_common/evas_gl_shader.c
>> > >
>> > > Modified: trunk/efl/ChangeLog
>> > > ===
>> > > --- trunk/efl/ChangeLog   2013-01-07 06:06:16 UTC (rev 82320)
>> > > +++ trunk/efl/ChangeLog   2013-01-07 06:16:18 UTC (rev 82321)
>> > > @@ -1,3 +1,12 @@
>> > > +2013-01-07 Sung W. Park (sung_)
>> > > +
>> > > + * Pulled out evas gl backend binary shader file caching code
>> from
>> > > +evas_gl_shader.c file and made an internal generic caching
>> api
>> > in
>> > > +evas_gl_common.h for use in evas_gl code.
>> > > +* Implemented evas_gl surface cap. caching code in gl
>> backend to
>> > > +accelerate the engine creation.
>> > > +
>> > > +
>> > >  2013-01-07  Thomas Petazzoni
>> > >
>> > >   * Fix build of Evas XCB backend.
>> > >
>> > > Modified: trunk/efl/src/Makefile_Evas.am
>> > > ===
>> > > --- trunk/efl/src/Makefile_Evas.am2013-01-07 06:06:16 UTC (rev
>> 82320)
>> > > +++ trunk/efl/src/Makefile_Evas.am2013-01-07 06:16:18 UTC (rev
>> 82321)
>> > > @@ -448,6 +448,7 @@
>> > >  modules/evas/engines/gl_common/evas_gl_private.h \
>> > >  modules/evas/engines/gl_common/evas_gl_commo

Re: [E-devel] [e-users] Korean E dinner

[Sung W. Park]

Raster & Hermet doing Gangnam style!  crazy!

by the way, if you guys are gonna try Vatos, I suggest that you call the
place and make a reservation (if possible)... they may be booked already.
otherwise you're looking at an hour wait at least!  but the food is
awesome!

http://blog.naver.com/gmdosk?Redirect=Log&logNo=70154958852

If you're looking for something else, I also would like to recommend "New
York Brick Oven Pizza" near Gangnam station.

http://blog.naver.com/crom776?Redirect=Log&logNo=150148599787

It's my favorite pizza place in Korea.  The owner was actually trained in
the states and he imports his key ingredients from the states.

i can't join this weekend but have a wonderful time!

cheers,
sung

On Thu, Jan 10, 2013 at 9:57 AM, Kim Shinwoo  wrote:

> -,.-)=b
>
> On Wed, Jan 9, 2013 at 8:26 PM, Jihoon Kim  wrote:
>
> > it's hot video I've ever seen :)
> > 2013. 1. 6. 오전 12:56에 "Daniel Juyung Seo" 님이 작성:
> >
> > > Everybody pants on!!!
> > >
> > > Raster and Hermet actually danced Gangnam Style in Itaewon just for 5
> > > seconds.
> > > Let's party.
> > >
> > > http://www.youtube.com/watch?v=qyS-HhlXmRE
> > >
> > > Daniel Juyung Seo (SeoZ)
> > >
> > > On Fri, Jan 4, 2013 at 9:19 PM, Carsten Haitzler  > > >wrote:
> > >
> > > > On Fri, 4 Jan 2013 19:27:32 +0900 Cedric BAIL 
> > > said:
> > > >
> > > > > On Fri, Jan 4, 2013 at 5:21 PM, Carsten Haitzler <
> > ras...@rasterman.com
> > > >
> > > > wrote:
> > > > > > On Fri, 4 Jan 2013 15:55:21 +0900 Cedric BAIL <
> cedric.b...@free.fr
> > >
> > > > said:
> > > > > >> On Fri, Jan 4, 2013 at 2:58 PM, Jérôme Pinot 
> > > > wrote:
> > > > > >> > On 01/04/13 14:51, Daniel Juyung Seo wrote:
> > > > > >> >> On Fri, Jan 4, 2013 at 2:47 PM, Carsten Haitzler
> > > > > >> >> wrote:
> > > > > >> >> > On Fri, 4 Jan 2013 13:23:43 +0900 Daniel Juyung Seo
> > > > > >> >> >  said:
> > > > > >> >> >
> > > > > >> >> > gangnam vs itaewon... FIGHT!
> > > > > >> >> >
> > > > > >> >> > /me sings "itaewon style" and dances in a silly fashion.
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >> Dance during the meeting :)
> > > > > >> >> I bring my camera if we meet at Itaewon.
> > > > > >> >
> > > > > >> > If Raster dances Gangnam style, I would LOVE going to Itaewon
> > :-D
> > > > > >>
> > > > > >> Ok, so it will be Itaewon if raster accept to dance Gangnam
> style.
> > > > > >> Hermet can show him how, I already saw him dancing ;-) If not,
> > then
> > > > > >> Gangnam.
> > > > > >>
> > > > > >> What times guy ? 7pm ?
> > > > > >
> > > > > > yargh... i can dance with my arms. theres never enough room to
> use
> > > your
> > > > > > legs... :)
> > > > >
> > > > > We will find the necessary room for that. So Itaewon tomorrow at 7
> at
> > > > > the subway exit in front of Paris baguette.
> > > >
> > > > i shall try remember my pants. u'll need to be fast with the camera.
> > > > dancing
> > > > may not last long. ;)
> > > >
> > > > --
> > > > - Codito, ergo sum - "I code, therefore I am"
> > --
> > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > > >
> > > >
> > > >
> > > >
> > >
> >
> --
> > > > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> > > > much more. Get web development skills now with LearnDevNow -
> > > > 350+ hours of step-by-step video tutorials by Microsoft MVPs and
> > experts.
> > > > SALE $99.99 this month only -- learn more at:
> > > > http://p.sf.net/sfu/learnmore_122812
> > > > ___
> > > > enlightenment-users mailing list
> > > > enlightenment-us...@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> > > >
> > >
> > >
> >
> --
> > > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> > > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > > MVPs and experts. SALE $99.99 this month only -- learn more at:
> > > http://p.sf.net/sfu/learnmore_122912
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> >
> --
> > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> > and much more. Keep your Java skills current with LearnJavaNow -
> > 200+ hours of step-by-step video tutorials by Java experts.
> > SALE $49.99 this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_122612
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >

Re: [E-devel] #2283: GLView works only for OpenGL X11 engine

[Sung W. Park]

Hi,

that's really weird..

I'm running Ubuntu 12.04 and I just installed libosmesa6-dev using apt-get
install and it works fine.

Which OSMesa have you tried this on?

I only opened OSMesa in the code because when I implemented it, libosmesa
contained all the GL symbols.

Maybe they separated it?  I guess I'll have to check it  out.

cheers,
Sung

On Tue, Mar 5, 2013 at 1:00 AM, E-Trac  wrote:

> #2283: GLView works only for OpenGL X11 engine
> +-
>  Reporter:  Dennis Schridde   |   Owner:  raster
>  Type:  Bug |  Status:  new
>  Priority:  Major   |   Milestone:
> Component:  evas|  Resolution:
>  Keywords:  |  Blocked By:
>  Blocking:  |
> +-
>
> Comment (by Dennis Schridde ):
>
>  The same issue exists on Ubuntu 12.04 (actually Bodhi 2.2):
>  ERR<25811>:evas_main evas_gl.c:42 evas_gl_new() Evas GL engine not
>  available.
>  ERR<25811>:elementary elm_glview.c:196 _elm_glview_smart_add() Failed
>  Creating an Evas GL Object.
>
> --
> Ticket URL: 
> Enlightenment 
> Enlightenment Project
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> ___
> enlightenment-bugs mailing list
> enlightenment-b...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-bugs
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

[Sung W. Park]

Hi all,

My name is Sung Park and I've recently started working on a project for a
Big mobile hw company in Korea ;-)
I've been given the assignment of getting the OpenGL rendered output set as
an image object in Evas, and now I'm getting my feet wet with EFL.

I'd very much appreciate your guys' help and comments.  Hopefully, I'll do
the same for the community in a short period of time.

So, here I go...
---
>From what I've gathered thus far, there is the

evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);

that allows you to either pass in a pixmap or a texture id as part of the
Evas_Native_Surface structure to set it as the evas_image object source.
I've noticed that the opengl texture part of the code hasn't been
implemented yet.  In fact, this is the part that we are interested in
currently:  to render an image using OpenGL to an output texture (using FBO)
and then to pass that texture to the above function.

Unfortunately, there are a few issues with this approach.   (By the way, I'm
assuming that Evas is running a gl-x11 engine for the sake of discussion)

- The main issue is that the GL application's GL context and the Evas
engine's GL context is different. Hence a texture created from the
application cannot be seen from the Evas engine's GL context and will not
output correct result.  I know that in Windows or Mac, there are ways to
share texture resources even across processes, but that is not the case in
Linux environment -- you can redirect pixmaps and bind it as a texture but
not explicitly share textures.

- However, there is a way to get around this issue.  Texture resources can
be shared across different contexts by giving the share context as a
parameter when creating a new context.  For example,

   glXCreateContext(Display* dpy, XVisualInfo *vis, GLXContext shareList,
Bool direct);

the shareList can be Evas' GL context.  Then when the user application
creates a GL context with this parameter, Evas will be able to see the
texture.  Unfortunately, this exposes Evas' resources to the users BUT there
isn't really a reasonably better option without writing a ton code...

However, explicitly exposing Evas' GL context just sound like a really
really bad idea.  One option that I would like to discuss over in a separate
thread is possibly having evas provide a set of open gl glue layer apis and
take care of the creating context and etc. for the users so they don't have
to explicitly deal with Evas' internals.

- There's also the make_current overhead for dynamic scenes since the
application and evas has to call make_current every time they render. I'll
address that again next time.

---

For this thread, I would like to ask the community to review
evas_object_image_native_surface_set portion of the code that I've added.
The patch that I'm including is for gl_x11 engine evas_engine.c and
gl_common's evas_gl_context.c.  I'm also including a simple sample program
that tests the code.  consider the code a minor fix that allows the sample
code to run and maybe you guys can help out completing it.

By the way, It's been quite difficult trying to figure out the semantics of
some of the evas_object_image functions without proper documentations... so
i may have gotten certain things wrong here..

Also, if you look at the sample code, I've used glXGetCurrentContext() to
grab Evas' current GL context to use it as a share context.  It's a dirty
trick but it allows me to test the code for now =)

I've also noticed that there was a y-invert texture coordinate bug (GL and
evas has different coordinate system) so I've made those changes in
evas_gl_context.c

___
Here are some comments about the changes I've made.

When using the image object, one would set the data using

   evas_object_image_data_set(obj, data);

and internally, this creates a Evas_GL_Image structure.  If I don't use the
above function, it doesn't create a Evas_GL_Image object.
For setting a native surface opengl texture, I figured it's not necessary to
call above function so i've added some code in the beginning of the
native_set() that creates the object if it's an OpenGL Native Surface.

Also, I didn't think it was necessary to hash the image object so i didn't
add the code in there but I could be wrong I guess.

Finally, I think it may not be a bad idea to add target (texture target)
field in the Evas_Native_Surface but I guess that can be debated.  For now,
i've just hard-coded the field with GL_TEXTURE_2D.

Sorry for the long email.

Your comments on the patches would be very much appreciated.

cheers,
Sung


native_surface_set.tgz
Description: GNU Zip compressed data
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applic

[E-devel] [RFC] Evas - OpenGL and Evas (Part 2)

[Sung W. Park]

Hi all,

In my earlier post, I've discussed about the issues with getting the

  evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);

function for setting OpenGL output texture.

The main issue was the GL application having to know Evas' GL context for
resource
sharing.  (refer to the older post if this doesn't make sense).  Exposing
Evas'
GL context is just a bad idea and it makes things really ugly.

One idea that Cedric mentioned as a response was to have evas provide APIs
that create OpenGL context for the user so everything can be hidden.

I actually had the same idea and the previous post was a way for me to setup
a
discussion ground for what I'm about to propose.

Instead of just exposing apis for creating contexts, I thought it would be
nice
for Evas to provide the OpenGL glue layer for the user.  When I say glue
layer,
I'm talking about GLX (for X evn in linux), WGL (for windows) and CGL (for
mac).
The Evas glue layer would provide functions such
as surface/context creation, make current function and etc.  this allows
evas to
hide all the backend specific code in the evas engine and have user deal
with
the provided APIs.  This goes along with EFL philosophy I believe.

For surface implementation, the engine can simply create an FBO and a
render target texture for the user to render to.  The texture can be used to
for setting the native_surface function.

There are two way to go about providing the APIs.  One approach is to have
evas fill out a list of functions from the engine.  This can be similar to
Evas_Engine_Info_GL_X11.

for example,
////
// Option 1
struct _Evas_GL_Info
{
   int  version;

   struct {
  Display  *display;
  Evas_GL_APIapi;
   } info;

   struct {
  Evas_GL_Contex*(*create_context)(Evas_GL_Info *info);
  Evas_GL_Surface   *(*create_surface)(Evas_GL_Info *info, const
Evas_GL_Config *config);
  Eina_Bool(*make_current)(Evas_GL_Info *info,
Evas_GL_Context *context, Evas_GL_Surface *surface);
  Evas_GL_Func(*get_proc_address)(const char *proc_name);
  const char  *(*query_extension)(void);
  // Need functions that destroy contexts and etc...
   } func;
};

EAPI Evas_GL_Info*evas_gl_info_get(Evas *e);

// Usage Example
int main()
{
   Evas e* = ...;

   Evas_GL_Info*glinfo;
   Evas_GL_Context *ctx;
   Evas_GL_Surface *sfc;
   Evas_GL_Config  cfg = {...};
   Evas_Native_Surface ns;

   glinfo = evas_gl_info_get(e);
   ctx = glinfo->func->create_context(glinfo, EVAS_GL_API_GLES_2);
   sfc = glinfo->func->create_surface(glinfo, cfg);

   glinfo->func->make_current(glinfo, ctx, sfc);

   // Use tex and the info in the surface to attach it to the image_object
   ns.data.opengl.texture_id = sfc->data.gl.tex;
   ...

   return 0;
}

////
Another option is to provide evas-like APIs.

// Option 2
EAPI Evas_GL  *evas_gl_new (Evas
*e);
EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL *evas_gl,
Evas_GL_Config *cfg, int w, int h);
EAPI Evas_EFGL_Context *evas_gl_context_create (Evas_GL *evas_gl);
EAPI Eina_Bool  evas_gl_make_current   (Evas_GL
*evas_gl, Evas_GL_Surface *sfc, Evas_EFGL_Context *ctx);
EAPI Evas_GL_Func  evas_gl_proc_address_get (Evas_GL *evas_gl,
const char *name);

EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
*evas_gl, Evas_GL_Surface *sfc, Evas_Native_Surface *ns);

// Usage Example
int main (void)
{
Evas e* = ...;

EvasGL *evasgl;
EvasGL_Surface *sfc;
EvasGL_Context *ctx;
EvasGL_Config cfg = { ... };
Evas_Native_Surface ns;

evasgl = evasgl_get(canvas);
sfc = evasgl_create_surface(evasgl, &cfg, w, h);
ctx = evasgl_create_context(evasgl);

evasgl_make_current(evasgl, sfc, ctx);

// GL Calls...
...

// Get the native surface from EvasGL surface to attach it to the image
object
evasgl_native_surface_get (evasgl, *sfc, &ns);
...
}

//--//
Personally, I like the option 2 because the APIs look more Evas-like and
it's evas engine neutral.

Now, there are a few issues with implementing a glue layer in Evas.

- One major issue is that internally, the surface that the evas provides is
implemented using an FBO. Semantically, FBO index 0 is the main framebuffer
of the screen.  So, when user calls, glBindFramebuffer(GL_FRAMEBUFFER, 0);
the user expects the framebuffer of the surface.  Unfortunately, this isn't
true
when using the evas provided surface. So we'll need to either advise
developers
not to call glBindFramebuffer(GL_FRAMEBUFFER, 0) or hook that
function and have it do what we want to do.  Another idea that came up is
have evas provide a list of GL functions that it supports. That can be
debated later.

- Another issue is that because the application would run in the sa

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

[Sung W. Park]

Hi Cedric,

Thanks for your quick response.  Sorry for my late response.  Yesterday was
a
Korean national holiday so I got to relax a little bit. =)

I'm going to respond to some of your comments below.  I'm glad that you're
picking
up the concerns that I have as well. In fact, I'll go ahead and start
another thread
with suggestions I have later.

On Mon, Feb 28, 2011 at 6:44 PM, Cedric BAIL  wrote:

> Hi,
>
> On Mon, Feb 28, 2011 at 9:14 AM, Sung W. Park  wrote:
> > My name is Sung Park and I've recently started working on a project for a
> > Big mobile hw company in Korea ;-)
> > I've been given the assignment of getting the OpenGL rendered output set
> as
> > an image object in Evas, and now I'm getting my feet wet with EFL.
>
> That's a terribly usefull and interesting project ! Good to know you
> are starting to work on it !
>

Yes, I this will make Evas more exciting I think, even though it's pretty
cool already.


> > I'd very much appreciate your guys' help and comments.  Hopefully, I'll
> do
> > the same for the community in a short period of time.
> >
> > So, here I go...
> > ---
> > >From what I've gathered thus far, there is the
> >
> >evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);
> >
> > that allows you to either pass in a pixmap or a texture id as part of the
> > Evas_Native_Surface structure to set it as the evas_image object source.
> > I've noticed that the opengl texture part of the code hasn't been
> > implemented yet.  In fact, this is the part that we are interested in
> > currently:  to render an image using OpenGL to an output texture (using
> FBO)
> > and then to pass that texture to the above function.
> >
> > Unfortunately, there are a few issues with this approach.   (By the way,
> I'm
> > assuming that Evas is running a gl-x11 engine for the sake of discussion)
>
> Well, I dislike that assumption. We really need to have something that
> work whatever the backend and the environment you are running on is
> running. OpenGL is not linked with X except during the initialisation
> process. From my point of view, it's critical that we completly hide
> that step from Evas users.
>
>
My assumption here was just for the sake of discussion.  It shows you the
dirtiness/
ugliness of this solution.  As you say, the whole X dependency needs to be
hidden.


> > - The main issue is that the GL application's GL context and the Evas
> > engine's GL context is different. Hence a texture created from the
> > application cannot be seen from the Evas engine's GL context and will not
> > output correct result.  I know that in Windows or Mac, there are ways to
> > share texture resources even across processes, but that is not the case
> in
> > Linux environment -- you can redirect pixmaps and bind it as a texture
> but
> > not explicitly share textures.
> >
> > - However, there is a way to get around this issue.  Texture resources
> can
> > be shared across different contexts by giving the share context as a
> > parameter when creating a new context.  For example,
> >
> >   glXCreateContext(Display* dpy, XVisualInfo *vis, GLXContext shareList,
> > Bool direct);
> >
> > the shareList can be Evas' GL context.  Then when the user application
> > creates a GL context with this parameter, Evas will be able to see the
> > texture.  Unfortunately, this exposes Evas' resources to the users BUT
> there
> > isn't really a reasonably better option without writing a ton code...
> >
> > However, explicitly exposing Evas' GL context just sound like a really
> > really bad idea.  One option that I would like to discuss over in a
> separate
> > thread is possibly having evas provide a set of open gl glue layer apis
> and
> > take care of the creating context and etc. for the users so they don't
> have
> > to explicitly deal with Evas' internals.
>
> I do agree that we should never expose Evas GL context or we will end
> in very deep trouble. I don't know if that's possible at all, but
> maybe we could let Evas create and provide a GL context that is
> correctly setup to share the texture created with it. Something that
> an upper library could reuse directly without taking care of the
> backend at all.
>
>
Yes, that's exactly what I'm thinking as well.
I'll propose a new sets of APIs in a new email thread.


> > - There's also the make_current overhead for dynamic scenes since the
> > application and evas has

Re: [E-devel] [RFC] Evas - OpenGL and Evas (Part 2)

[Sung W. Park]

Hi Cedric,

On Thu, Mar 3, 2011 at 1:30 AM, Cedric BAIL  wrote:

> Hi,
>
> I will do just a quick answer, I don't know if I will have time to
> come back on this subject later.
>

that's fine.   =)


>
> On Wed, Mar 2, 2011 at 5:41 AM, Sung W. Park  wrote:
> > Hi all,
> >
> > In my earlier post, I've discussed about the issues with getting the
> >
> >  evas_object_image_native_surface_set(..., Evas_Native_Surface
> *surf);
> >
> > function for setting OpenGL output texture.
> >
> > The main issue was the GL application having to know Evas' GL context for
> > resource
> > sharing.  (refer to the older post if this doesn't make sense).  Exposing
> > Evas'
> > GL context is just a bad idea and it makes things really ugly.
> >
> > One idea that Cedric mentioned as a response was to have evas provide
> APIs
> > that create OpenGL context for the user so everything can be hidden.
> >
> > I actually had the same idea and the previous post was a way for me to
> setup
> > a
> > discussion ground for what I'm about to propose.
> >
> > Instead of just exposing apis for creating contexts, I thought it would
> be
> > nice
> > for Evas to provide the OpenGL glue layer for the user.  When I say glue
> > layer,
> > I'm talking about GLX (for X evn in linux), WGL (for windows) and CGL
> (for
> > mac).
> > The Evas glue layer would provide functions such
> > as surface/context creation, make current function and etc.  this allows
> > evas to
> > hide all the backend specific code in the evas engine and have user deal
> > with
> > the provided APIs.  This goes along with EFL philosophy I believe.
> >
> > For surface implementation, the engine can simply create an FBO and a
> > render target texture for the user to render to.  The texture can be used
> to
> > for setting the native_surface function.
> >
> > There are two way to go about providing the APIs.  One approach is to
> have
> > evas fill out a list of functions from the engine.  This can be similar
> to
> > Evas_Engine_Info_GL_X11.
> >
> > for example,
> > ////
> > // Option 1
> > struct _Evas_GL_Info
> > {
> >   int  version;
> >
> >   struct {
> >  Display  *display;
> >  Evas_GL_APIapi;
> >   } info;
> >
> >   struct {
> >  Evas_GL_Contex*(*create_context)(Evas_GL_Info *info);
> >  Evas_GL_Surface   *(*create_surface)(Evas_GL_Info *info, const
> > Evas_GL_Config *config);
> >  Eina_Bool(*make_current)(Evas_GL_Info *info,
> > Evas_GL_Context *context, Evas_GL_Surface *surface);
> >  Evas_GL_Func(*get_proc_address)(const char *proc_name);
> >  const char  *(*query_extension)(void);
> >  // Need functions that destroy contexts and etc...
> >   } func;
> > };
> >
> > EAPI Evas_GL_Info*evas_gl_info_get(Evas *e);
> >
> > // Usage Example
> > int main()
> > {
> >   Evas e* = ...;
> >
> >   Evas_GL_Info*glinfo;
> >   Evas_GL_Context *ctx;
> >   Evas_GL_Surface *sfc;
> >   Evas_GL_Config  cfg = {...};
> >   Evas_Native_Surface ns;
> >
> >   glinfo = evas_gl_info_get(e);
> >   ctx = glinfo->func->create_context(glinfo, EVAS_GL_API_GLES_2);
> >   sfc = glinfo->func->create_surface(glinfo, cfg);
> >
> >   glinfo->func->make_current(glinfo, ctx, sfc);
> >
> >   // Use tex and the info in the surface to attach it to the image_object
> >   ns.data.opengl.texture_id = sfc->data.gl.tex;
> >   ...
> >
> >   return 0;
> > }
> >
> > ////
> > Another option is to provide evas-like APIs.
> >
> > // Option 2
> > EAPI Evas_GL  *evas_gl_new (Evas
> > *e);
> > EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL
> *evas_gl,
> > Evas_GL_Config *cfg, int w, int h);
> > EAPI Evas_EFGL_Context *evas_gl_context_create (Evas_GL
> *evas_gl);
> > EAPI Eina_Bool  evas_gl_make_current   (Evas_GL
> > *evas_gl, Evas_GL_Surface *sfc, Evas_EFGL_Context *ctx);
> > EAPI Evas_GL_Func  evas_gl_proc_address_get (Evas_GL
> *evas_gl,
> > const char *name);
> >
> > EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
> > *evas_gl, Evas_GL_Surface *sfc, Evas_Nati

[E-devel] [RFC] Evas - OpenGL and Evas (Part 3)

[Sung W. Park]

Hi all,

In my earlier post, I've discussed about the issues with getting the

  evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);

function for setting OpenGL output texture.   There was also a disucssion
about how Evas should provide a GL glue layer.  We've discussed two
proposals.
After some discussion, I went ahead with the preferred way and have
implemented the APIs.

The APIs go something like... (in Evas_GL.h)

   EAPI Evas_GL *evas_gl_new  (Evas *e);
   EAPI Evas_GL_Surface*evas_gl_surface_create  (Evas_GL *evas_gl,
Evas_GL_Config *cfg, int w, int h);
   EAPI Evas_GL_Context*evas_gl_context_create  (Evas_GL *evas_gl,
Evas_GL_Context *share_ctx);
   EAPI Eina_Bool evas_gl_make_current(Evas_GL
*evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
   EAPI Evas_GL_Func evas_gl_proc_address_get   (Evas_GL *evas_gl,
const char *name);

   EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
*evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);

I actually have the above APIs running on my machine but
instead of dumping the entire thing, I wanted to get incremental comments
for review.

I'm now attaching Evas_GL.h and evas_gl.c and a Sample program that uses the
APIs.

Your comments would be very much appreciated.  After the initial review,
I'll submit
a RFC for the engine part of the code that I wrote for gl_x11 module.

One issue that I ran into with the above APIs is that Evas_GL_Context is
already used
by the gl_common part of the code in the engine module.  Upon discussing it
with Raster,
the consensus was that it was better to change the internal code since it's
not exposed.
So, in my implementation, I've changed the internal part to
Evas_Engine_GL_Context.
I just wanted to mention that here for now even though it won't show in the
files that i'm
attaching.

thanks!
Sung
#ifndef _EVAS_GL_H
#define _EVAS_GL_H

#include 

#ifdef __cplusplus
extern "C" {
#endif

typedef struct _Evas_GL   Evas_GL;
typedef struct _Evas_GL_Surface   Evas_GL_Surface;
typedef struct _Evas_GL_Context   Evas_GL_Context;
typedef struct _Evas_GL_ConfigEvas_GL_Config;
typedef void* Evas_GL_Func;

typedef enum _Evas_GL_Color_Format
{
EVAS_GL_RGB_8,  // 8 bits per channel
EVAS_GL_RGBA_8,
EVAS_GL_RGB_32, // 32-bits per channel
EVAS_GL_RGBA_32,
} Evas_GL_Color_Format;

typedef enum _Evas_GL_Depth_Bits
{
EVAS_GL_DEPTH_BIT_8,
EVAS_GL_DEPTH_BIT_16,
EVAS_GL_DEPTH_BIT_24,
EVAS_GL_DEPTH_BIT_32,
EVAS_GL_DEPTH_NONE
} Evas_GL_Depth_Bits;

typedef enum _Evas_GL_Stencil_Bits
{
EVAS_GL_STENCIL_BIT_1,
EVAS_GL_STENCIL_BIT_2,
EVAS_GL_STENCIL_BIT_4,
EVAS_GL_STENCIL_BIT_8,
EVAS_GL_STENCIL_BIT_16,
EVAS_GL_STENCIL_NONE
} Evas_GL_Stencil_Bits;

struct _Evas_GL_Config
{
Evas_GL_Color_Format color_format;
Evas_GL_Depth_Bits   depth_bits;
Evas_GL_Stencil_Bits stencil_bits;
};

/**
 * @defgroup Evas_GL group for rendering GL on Evas
 *
 * Functions that are used to do GL rendering on Evas.
 *
 * @ingroup Evas_Canvas
 */

   EAPI Evas_GL *evas_gl_new(Evas *e);
   EAPI void evas_gl_free   (Evas_GL *evas_gl);
   EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL *evas_gl, Evas_GL_Config *cfg, int w, int h);
   EAPI void evas_gl_surface_destroy(Evas_GL *evas_gl, Evas_GL_Surface *surf); 
   EAPI Evas_GL_Context *evas_gl_context_create (Evas_GL *evas_gl, Evas_GL_Context *share_ctx); 
   EAPI void evas_gl_context_destroy(Evas_GL *evas_gl, Evas_GL_Context *ctx); 
   EAPI Eina_Boolevas_gl_make_current   (Evas_GL *evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
   EAPI Evas_GL_Func evas_gl_proc_address_get   (Evas_GL *evas_gl, const char *name);

   EAPI Eina_Boolevas_gl_native_surface_get (Evas_GL *evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);
 
//   EAPI Evas_GL *evas_gl_api_get(Evas *e, Evas_GL_API *glapi) EINA_ARG_NONNULL(1, 2);

#ifdef __cplusplus
}
#endif

#endif
#include "evas_common.h"
#include "evas_private.h"
#include "Evas_GL.h"

struct _Evas_GL
{
   int  magic;
   Evas*evas;
};

struct _Evas_GL_Context
{
   void*data;
};

struct _Evas_GL_Surface
{
   void*data;
};


/**
 * @addtogroup Evas_GL
 * @{
 */

/**
 * Creates a new Evas_GL object and returns a handle for gl rendering on efl.
 *
 * @param e The given evas.
 * @return The created evas_gl object.
 */
EAPI Evas_GL *
evas_gl_new(Evas *e)
{
   Evas_GL *evas_gl;

   evas_gl = calloc(1, sizeof(Evas_GL));
   if (!evas_gl) return NULL;

   evas_gl->magic = MAGIC_EVAS_GL;
   evas_gl->evas = e;

   return evas_gl;
}

/**
 * Frees the created Evas_GL object.
 *
 * @param evas_gl The given Evas_G

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

[Sung W. Park]

Ah, i see that you finally had a chance to go through your email piles =)
welcome back!

On Thu, Mar 10, 2011 at 5:52 PM, Carsten Haitzler wrote:

> On Mon, 28 Feb 2011 17:14:58 +0900 "Sung W. Park" 
> said:
>
> > Hi all,
> >
> > My name is Sung Park and I've recently started working on a project for a
> > Big mobile hw company in Korea ;-)
>
> oh out with it already! :) everyone knows its samsung. :)
>

ok, i didn't say it =P


>
> > I've been given the assignment of getting the OpenGL rendered output set
> as
> > an image object in Evas, and now I'm getting my feet wet with EFL.
>
> slosh slosh. welcome to our little corner of the swamp :)
>
> > I'd very much appreciate your guys' help and comments.  Hopefully, I'll
> do
> > the same for the community in a short period of time.
> >
> > So, here I go...
> > ---
> > >From what I've gathered thus far, there is the
> >
> > evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);
> >
> > that allows you to either pass in a pixmap or a texture id as part of the
> > Evas_Native_Surface structure to set it as the evas_image object source.
> > I've noticed that the opengl texture part of the code hasn't been
> > implemented yet.  In fact, this is the part that we are interested in
> > currently:  to render an image using OpenGL to an output texture (using
> FBO)
> > and then to pass that texture to the above function.
> >
> > Unfortunately, there are a few issues with this approach.   (By the way,
> I'm
> > assuming that Evas is running a gl-x11 engine for the sake of discussion)
> >
> > - The main issue is that the GL application's GL context and the Evas
> > engine's GL context is different. Hence a texture created from the
> > application cannot be seen from the Evas engine's GL context and will not
> > output correct result.  I know that in Windows or Mac, there are ways to
> > share texture resources even across processes, but that is not the case
> in
> > Linux environment -- you can redirect pixmaps and bind it as a texture
> but
> > not explicitly share textures.
> >
> > - However, there is a way to get around this issue.  Texture resources
> can
> > be shared across different contexts by giving the share context as a
> > parameter when creating a new context.  For example,
> >
> >glXCreateContext(Display* dpy, XVisualInfo *vis, GLXContext shareList,
> > Bool direct);
> >
> > the shareList can be Evas' GL context.  Then when the user application
> > creates a GL context with this parameter, Evas will be able to see the
> > texture.  Unfortunately, this exposes Evas' resources to the users BUT
> there
> > isn't really a reasonably better option without writing a ton code...
> >
> > However, explicitly exposing Evas' GL context just sound like a really
> > really bad idea.  One option that I would like to discuss over in a
> separate
> > thread is possibly having evas provide a set of open gl glue layer apis
> and
> > take care of the creating context and etc. for the users so they don't
> have
> > to explicitly deal with Evas' internals.
> >
> > - There's also the make_current overhead for dynamic scenes since the
> > application and evas has to call make_current every time they render.
> I'll
> > address that again next time.
>
> actually i suspect we'll have to accept that there will always be some
> overhead in this whole gl on top of evas thing compared to gl directly in a
> window/buffer/fb yourself, so i don't think it will be TOO bad.
>

i agree.


>
> > ---
> >
> > For this thread, I would like to ask the community to review
> > evas_object_image_native_surface_set portion of the code that I've added.
> > The patch that I'm including is for gl_x11 engine evas_engine.c and
> > gl_common's evas_gl_context.c.  I'm also including a simple sample
> program
> > that tests the code.  consider the code a minor fix that allows the
> sample
> > code to run and maybe you guys can help out completing it.
> >
> > By the way, It's been quite difficult trying to figure out the semantics
> of
> > some of the evas_object_image functions without proper documentations...
> so
> > i may have gotten certain things wrong here..
> >
> > Also, if you look at the sample code, I've used glXGetCurrentContext() to
> >

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

[Sung W. Park]

Hi again,

Ok, I'm attaching a new patch.  Read comments below.

On Mon, Mar 14, 2011 at 10:49 AM, Sung W. Park  wrote:

> comments here: :)
>>
>> evas_gl_context.patch:
>> yup! in. i just never handled the y invert case (or lets say.. the
>> non-inverted
>> case). i just never encountered it so i n
>>
>
>> gl_x11_evas_engine.patch:
>> surprisingly... i have very little to grumble about. the only thing is the
>> hash
>> thing where you comments "i didn't think it was necessary...". as such you
>> can
>> get away with not doing it until you try and duplicate the same texture in
>> multiple image objects. the compositor does this - or can do it (and it is
>> used
>> for some effects like exposee).  this means it will share the same gl
>> image
>> wrapper struct etc. etc. which saves some resources.
>>
>> what you need to do here is put the image in a hash - like the one that
>> uses
>> pixmap id, but here using texture id. so u'll need another native_hash so
>> that
>> id's dont clash (tex id vs pixmap id) and then put it in there and take it
>> out
>> of it just like the native_hash stuff is done for pixmap id's. :)
>>
>
> my thoughts were that it wouldn't be a big overhead to just create new
> image objects
> for each texture reference but you're right in that it does save resources
> if you reference them.
>
> by the way, is there a good way to create a unique ID that i can use for
> hashing?
> since pixmap IDs are globally unique, it's good to use it as hash keys but
> I think using
> texture IDs would be a bad idea since it's context specific.  any thoughts
> on that?
>
>
>
nevermind.  i see your point. =)  since we're in one gl context (or context
that
shares resources), i think just using texture IDs should guarantee its
uniqueness.
i've renamed the original native_hash to native_pm_hash and created a new
one
called native_tex_hash.  i've also added the code that references image
object
if one exists already.

One thing that I didn't add was in _native_free_cb, I didn't know whether I
should free
up the texture there or not.  Any thoughts on this here?

Regards,
Sung


evas_native_set.tgz
Description: GNU Zip compressed data
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas - OpenGL and Evas (Part 3)

[Sung W. Park]

I forgot to do a "reply all" in my last reply. Anyway... I'll continue on
with the
discussion.

On Mon, Mar 14, 2011 at 11:04 AM, Sung W. Park  wrote:

> Hi~
>
> On Thu, Mar 10, 2011 at 6:11 PM, Carsten Haitzler wrote:
>
>> On Mon, 7 Mar 2011 17:33:00 +0900 "Sung W. Park" 
>> said:
>>
>> ok - i skipped all the way to this mail since this already was discussed
>> and
>> you've moved on 1 step. :)
>>
>> > Hi all,
>> >
>> > In my earlier post, I've discussed about the issues with getting the
>> >
>> >   evas_object_image_native_surface_set(..., Evas_Native_Surface
>> *surf);
>> >
>> > function for setting OpenGL output texture.   There was also a
>> disucssion
>> > about how Evas should provide a GL glue layer.  We've discussed two
>> > proposals.
>> > After some discussion, I went ahead with the preferred way and have
>> > implemented the APIs.
>> >
>> > The APIs go something like... (in Evas_GL.h)
>> >
>> >EAPI Evas_GL *evas_gl_new  (Evas
>> *e);
>> >EAPI Evas_GL_Surface*evas_gl_surface_create  (Evas_GL
>> *evas_gl,
>> > Evas_GL_Config *cfg, int w, int h);
>> >EAPI Evas_GL_Context*evas_gl_context_create  (Evas_GL
>> *evas_gl,
>> > Evas_GL_Context *share_ctx);
>> >EAPI Eina_Bool evas_gl_make_current(Evas_GL
>> > *evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
>> >EAPI Evas_GL_Func evas_gl_proc_address_get   (Evas_GL
>> *evas_gl,
>> > const char *name);
>> >
>> >EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
>> > *evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);
>> >
>> > I actually have the above APIs running on my machine but
>> > instead of dumping the entire thing, I wanted to get incremental
>> comments
>> > for review.
>>
>> thats actually really sensible :) most happy with the way you're handling
>> this.
>> do some local experiments - see if something works at all or not, see if
>> you
>> feel comfortable with it, then propose the idea/solution before you go too
>> much
>> further and flesh it out so as not to waste time. :)
>>
>> what you have there looks very sensible to me. its the "necessary" bits
>> you'd
>> find in EGL/glX etc. etc. needed to bind gl to evas.. BUT in a way that
>> returns
>> handles so evas can deal with it nicely :)
>>
>> one thing that an eventual implementation of this will need is both a "gl"
>> and
>> "software" path. the software path may literally us importing a special
>> build
>> of mesa with all the software rendering only enabled and glued to render
>> to
>> ARGB software buffers. how precisely this will happen/work in detail is a
>> matter i guess for actual implementation, BUT it will be needed as we have
>> to
>> "not fail" if you switch engines to software. be slower, sure. fail
>> (either
>> crash, have missing symbols or just whole parts of the canvas go
>> unrendered) is
>> bad.
>>
>> we dont need to do this right away, BUT we do need to "design for this"
>> and at
>> the api level that looks all perfectly possible.
>>
>
> Well, i have i the gl_x11 engine code up and running already so going too
> far isn't an
> issue.  it's too late.  =)  but i don't mind going back and changing things
> up.  it's not too
> bad actually.  also, i just wanted to get my feet wet and so it was a good
> exercise.  now,
> i just need to test it a little more before i can post a patch.
>
> as you've mentioned, you wouldn't have a problem attaching a software
> implementation of GL
> with this design.  it would have to be tested... i'll do that eventually.
>
>
>>
>> > I'm now attaching Evas_GL.h and evas_gl.c and a Sample program that uses
>> the
>> > APIs.
>> >
>> > Your comments would be very much appreciated.  After the initial review,
>> > I'll submit
>> > a RFC for the engine part of the code that I wrote for gl_x11 module.
>> >
>> > One issue that I ran into with the above APIs is that Evas_GL_Context is
>> > already used
>> > by the gl_common part of the code in the engine module.  Upon discussing
>> it
>> > with Raster,
>> > the consensus was that it was better t

[E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

Hi all,

Based on the discussions and the comments that I've been getting, I'm
attaching
patches for the community to review and test out the code. The patches
implement
the code for the gl_x11 backend.  Other backends can be taken care of later
once this has been reviewed.

I apologize if this patch seems a bit big.  I felt that we've had enough
discussions
on this topic already in increments and now we're at a point where we can
see this
prototype.

Here are the description of the patches:
(by the way, apply the patches by giving -p0 from evas directory)

1. Evas_Engine_GL_Context.patch
  - Basically, this patch replaces all the instances of Evas_GL_Context used
by the gl engines to Evas_Engine_GL_Context.  This was changed because
Evas_GL_Context is exposed to the users by Evas_GL.h and this was ok'ed
in the previous discussion.

2. evas_gl.patch
  - This patch includes the image_object_native_surface_set() patch
since it's required to run evas_gl and this patch hasn't been reflected
in the svn yet.
  - And, it has the rest of the code that allows evas_gl to run for gl_x11
engine.

3. Evas_GL.h
  - Instead of putting it as part of the patch, I've included them
separately so it
can be viewed easily.
  - This files goes in
src/lib/

4. evas_gl.c
  - Instead of putting it as part of the patch, I've included them
separately so it
can be viewed easily.
  - This files goes in
src/lib/canvas/

5. examples/
  - I've included 3 sample programs + Makefile
a. evasglsample1.c (a simple triangle using GL)
b. evasglgears.c (famous gears using Evas_GL)
c. evasglessample1.c (a simple triangle using GLES)
  - You can simply do a make in the directory and it'll compile the
evaglsampl1
and evasglgears by default.


I just tested with a fresh co from SVN and have applied the patches.  I hope
it works.

thanks in advance for your comments!

cheers,
Sung


evas_gl.tgz
Description: GNU Zip compressed data
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

Hi Cedric,

Thanks for the review and the comments.  I'm glad to hear that it worked =)

On Wed, Mar 16, 2011 at 11:35 PM, Cedric BAIL  wrote:

> Hi,
>
> On Wed, Mar 16, 2011 at 8:26 AM, Sung W. Park  wrote:
> > Based on the discussions and the comments that I've been getting, I'm
> > attaching
> > patches for the community to review and test out the code. The patches
> > implement
> > the code for the gl_x11 backend.  Other backends can be taken care of
> later
> > once this has been reviewed.
> >
> > I apologize if this patch seems a bit big.  I felt that we've had enough
> > discussions
> > on this topic already in increments and now we're at a point where we can
> > see this
> > prototype.
>
> I don't think them to big, they are really easy to understand and
> follow. I really like that !
>
> > Here are the description of the patches:
> > (by the way, apply the patches by giving -p0 from evas directory)
> >
> > 1. Evas_Engine_GL_Context.patch
> >  - Basically, this patch replaces all the instances of Evas_GL_Context
> used
> >by the gl engines to Evas_Engine_GL_Context.  This was changed because
> >Evas_GL_Context is exposed to the users by Evas_GL.h and this was
> ok'ed
> >in the previous discussion.
>
> Ok, just reading it. Why do you need to add :
> +#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
> +#include 
> +#else
> +#include 
> +#endif
>

This part of the code should not be there!  It was from the previous hack
that I did to expose the Evas' GL context.  It was a foolish was but
it did help me get my feet wet.  I thought I deleted it but it managed to
hide in there somehow.  You can just delete it and it works fine.



>
> in src/modules/engines/gl_x11/Evas_Engine_GL_X11.h . What is the
> purpose of this patch ? And why do you use evas private configure
> define in a public header ?
>
> By the way the rest of the patch is ok to go in as it is.
>
> > 2. evas_gl.patch
> >  - This patch includes the image_object_native_surface_set() patch
> >since it's required to run evas_gl and this patch hasn't been
> reflected
> >in the svn yet.
> >  - And, it has the rest of the code that allows evas_gl to run for gl_x11
> > engine.
>
> It seems you are currently destroying a surface using evas context
> instead of the right context, because it could be destroyed. Maybe I
> am wrong, but couldn't you implement a refcount attached to the user
> context to prevent destruction as long as some surface are attached to
> it. The rest of the patch looks good to me. Now we should wait for the
> software version :-) Hum, maybe it would be good Vincent if you could
> review it to, so we are sure nothing goes wrong when you try to port
> this feature on Windows (I don't see anything obvious, but more eyes
> is always better).
>
>
Essentially, Evas_GL_Surface is implemented using an FBO and a
texture and the texture can be seen both by the Evas' GL context and
then user created context.  the reason why I'm using Evas' context in
the surface_destroy code instead of using the user context is because
the user context can be destroyed first.  I could potentially keep a ref
count on the context and destroy it together but I didn't see a point in
doing that here.  it would work just fine using Evas' GL context.
that's why i make sure that i unbind the context once i use it.  maybe
there is an angle that i'm not seeing here though.  i'm definitely open
to suggestions. =)



> > 3. Evas_GL.h
> >  - Instead of putting it as part of the patch, I've included them
> > separately so it
> >can be viewed easily.
> >  - This files goes in
> >src/lib/
>
> > 4. evas_gl.c
> >  - Instead of putting it as part of the patch, I've included them
> > separately so it
> >can be viewed easily.
> >  - This files goes in
> >src/lib/canvas/
>
> Maybe in evas_gl_new you should check the validity of the Evas object.
> And before calling any evas_gl->evas->engine.func, you should check if
> they are correctly set. That's for the obvious, don't see much more
> than that.
>
> Good point!  I'll add that =)


> > 5. examples/
> >  - I've included 3 sample programs + Makefile
> >a. evasglsample1.c (a simple triangle using GL)
> >b. evasglgears.c (famous gears using Evas_GL)
> >c. evasglessample1.c (a simple triangle using GLES)
> >  - You can simply do a make in the directory and it'll compile the
> > evaglsampl1
> >and evasglgears by def

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

Hi again,

On Thu, Mar 17, 2011 at 2:39 AM, Cedric BAIL  wrote:

> Hi again,
>
> On Wed, Mar 16, 2011 at 5:02 PM, Sung W. Park  wrote:
> > Hi Cedric,
> > Thanks for the review and the comments.  I'm glad to hear that it worked
> =)
> >
> > On Wed, Mar 16, 2011 at 11:35 PM, Cedric BAIL 
> wrote:
> >> On Wed, Mar 16, 2011 at 8:26 AM, Sung W. Park 
> wrote:
> >> > Based on the discussions and the comments that I've been getting, I'm
> >> > attaching
> >> > patches for the community to review and test out the code. The patches
> >> > implement
> >> > the code for the gl_x11 backend.  Other backends can be taken care of
> >> > later
> >> > once this has been reviewed.
> >> >
> >> > I apologize if this patch seems a bit big.  I felt that we've had
> enough
> >> > discussions
> >> > on this topic already in increments and now we're at a point where we
> >> > can
> >> > see this
> >> > prototype.
> >>
> >> I don't think them to big, they are really easy to understand and
> >> follow. I really like that !
> >>
> >> > Here are the description of the patches:
> >> > (by the way, apply the patches by giving -p0 from evas directory)
> >> >
> >> > 1. Evas_Engine_GL_Context.patch
> >> >  - Basically, this patch replaces all the instances of Evas_GL_Context
> >> > used
> >> >by the gl engines to Evas_Engine_GL_Context.  This was changed
> >> > because
> >> >Evas_GL_Context is exposed to the users by Evas_GL.h and this was
> >> > ok'ed
> >> >in the previous discussion.
> >>
> >> Ok, just reading it. Why do you need to add :
> >> +#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
> >> +#include 
> >> +#else
> >> +#include 
> >> +#endif
> >
> > This part of the code should not be there!  It was from the previous hack
> > that I did to expose the Evas' GL context.  It was a foolish was but
> > it did help me get my feet wet.  I thought I deleted it but it managed to
> > hide in there somehow.  You can just delete it and it works fine.
>
> So that one is in svn. I also added you in the AUTHORS file, if you
> prefer another mail address, please let me know.
>

Great!  That email address is fine.  wow, thanks.


>
> >> in src/modules/engines/gl_x11/Evas_Engine_GL_X11.h . What is the
> >> purpose of this patch ? And why do you use evas private configure
> >> define in a public header ?
> >>
> >> By the way the rest of the patch is ok to go in as it is.
> >>
> >> > 2. evas_gl.patch
> >> >  - This patch includes the image_object_native_surface_set() patch
> >> >since it's required to run evas_gl and this patch hasn't been
> >> > reflected
> >> >in the svn yet.
> >> >  - And, it has the rest of the code that allows evas_gl to run for
> >> > gl_x11
> >> > engine.
> >>
> >> It seems you are currently destroying a surface using evas context
> >> instead of the right context, because it could be destroyed. Maybe I
> >> am wrong, but couldn't you implement a refcount attached to the user
> >> context to prevent destruction as long as some surface are attached to
> >> it. The rest of the patch looks good to me. Now we should wait for the
> >> software version :-) Hum, maybe it would be good Vincent if you could
> >> review it to, so we are sure nothing goes wrong when you try to port
> >> this feature on Windows (I don't see anything obvious, but more eyes
> >> is always better).
> >>
> >
> > Essentially, Evas_GL_Surface is implemented using an FBO and a
> > texture and the texture can be seen both by the Evas' GL context and
> > then user created context.  the reason why I'm using Evas' context in
> > the surface_destroy code instead of using the user context is because
> > the user context can be destroyed first.  I could potentially keep a ref
> > count on the context and destroy it together but I didn't see a point in
> > doing that here.  it would work just fine using Evas' GL context.
> > that's why i make sure that i unbind the context once i use it.  maybe
> > there is an angle that i'm not seeing here though.  i'm definitely open
> > to suggestions. =)
>
> Well, it works, it's just it

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

Hi Daniel,

Can you elaborate on what you mean by making this as a patch?

I've sent two patches for the files that need to be updated, one of which
has been applied
already.  The other one has been reviewed a little but hasn't been applied
yet.

As for the other files, they need to be freshly added to the svn and since i
don't have
commit access, i've just attached them separately.

Let me know what you mean by it.

cheers,
Sung



On Thu, Mar 24, 2011 at 12:32 AM, Daniel Juyung Seo wrote:

> Can you make this as a patch?
>
> Thanks.
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Mar 17, 2011 at 11:34 PM, Sung W. Park  wrote:
> > Hi again,
> >
> > On Thu, Mar 17, 2011 at 2:39 AM, Cedric BAIL 
> wrote:
> >
> >> Hi again,
> >>
> >> On Wed, Mar 16, 2011 at 5:02 PM, Sung W. Park 
> wrote:
> >> > Hi Cedric,
> >> > Thanks for the review and the comments.  I'm glad to hear that it
> worked
> >> =)
> >> >
> >> > On Wed, Mar 16, 2011 at 11:35 PM, Cedric BAIL 
> >> wrote:
> >> >> On Wed, Mar 16, 2011 at 8:26 AM, Sung W. Park 
> >> wrote:
> >> >> > Based on the discussions and the comments that I've been getting,
> I'm
> >> >> > attaching
> >> >> > patches for the community to review and test out the code. The
> patches
> >> >> > implement
> >> >> > the code for the gl_x11 backend.  Other backends can be taken care
> of
> >> >> > later
> >> >> > once this has been reviewed.
> >> >> >
> >> >> > I apologize if this patch seems a bit big.  I felt that we've had
> >> enough
> >> >> > discussions
> >> >> > on this topic already in increments and now we're at a point where
> we
> >> >> > can
> >> >> > see this
> >> >> > prototype.
> >> >>
> >> >> I don't think them to big, they are really easy to understand and
> >> >> follow. I really like that !
> >> >>
> >> >> > Here are the description of the patches:
> >> >> > (by the way, apply the patches by giving -p0 from evas directory)
> >> >> >
> >> >> > 1. Evas_Engine_GL_Context.patch
> >> >> >  - Basically, this patch replaces all the instances of
> Evas_GL_Context
> >> >> > used
> >> >> >by the gl engines to Evas_Engine_GL_Context.  This was changed
> >> >> > because
> >> >> >Evas_GL_Context is exposed to the users by Evas_GL.h and this
> was
> >> >> > ok'ed
> >> >> >in the previous discussion.
> >> >>
> >> >> Ok, just reading it. Why do you need to add :
> >> >> +#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
> >> >> +#include 
> >> >> +#else
> >> >> +#include 
> >> >> +#endif
> >> >
> >> > This part of the code should not be there!  It was from the previous
> hack
> >> > that I did to expose the Evas' GL context.  It was a foolish was but
> >> > it did help me get my feet wet.  I thought I deleted it but it managed
> to
> >> > hide in there somehow.  You can just delete it and it works fine.
> >>
> >> So that one is in svn. I also added you in the AUTHORS file, if you
> >> prefer another mail address, please let me know.
> >>
> >
> > Great!  That email address is fine.  wow, thanks.
> >
> >
> >>
> >> >> in src/modules/engines/gl_x11/Evas_Engine_GL_X11.h . What is the
> >> >> purpose of this patch ? And why do you use evas private configure
> >> >> define in a public header ?
> >> >>
> >> >> By the way the rest of the patch is ok to go in as it is.
> >> >>
> >> >> > 2. evas_gl.patch
> >> >> >  - This patch includes the image_object_native_surface_set() patch
> >> >> >since it's required to run evas_gl and this patch hasn't been
> >> >> > reflected
> >> >> >in the svn yet.
> >> >> >  - And, it has the rest of the code that allows evas_gl to run for
> >> >> > gl_x11
> >> >> > engine.
> >> >>
> >> >> It seems you are currently destroying a surface using evas context
> >> &g

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

[Sung W. Park]

oh great!  I guess you finally got around to it =)

On Fri, Mar 25, 2011 at 1:57 PM, Carsten Haitzler wrote:

> On Mon, 14 Mar 2011 10:49:10 +0900 "Sung W. Park" 
> said:
>
> > Ah, i see that you finally had a chance to go through your email piles =)
> > welcome back!
>
> and now... another email pile is being conquered... i hope :)
>
> > > gl_x11_evas_engine.patch:
> > > surprisingly... i have very little to grumble about. the only thing is
> the
> > > hash
> > > thing where you comments "i didn't think it was necessary...". as such
> you
> > > can
> > > get away with not doing it until you try and duplicate the same texture
> in
> > > multiple image objects. the compositor does this - or can do it (and it
> is
> > > used
> > > for some effects like exposee).  this means it will share the same gl
> image
> > > wrapper struct etc. etc. which saves some resources.
> > >
> > > what you need to do here is put the image in a hash - like the one that
> > > uses
> > > pixmap id, but here using texture id. so u'll need another native_hash
> so
> > > that
> > > id's dont clash (tex id vs pixmap id) and then put it in there and take
> it
> > > out
> > > of it just like the native_hash stuff is done for pixmap id's. :)
> >
> > my thoughts were that it wouldn't be a big overhead to just create new
> image
> > objects
> > for each texture reference but you're right in that it does save
> resources
> > if you reference them.
> >
> > by the way, is there a good way to create a unique ID that i can use for
> > hashing?
> > since pixmap IDs are globally unique, it's good to use it as hash keys
> but I
> > think using
> > texture IDs would be a bad idea since it's context specific.  any
> thoughts
> > on that?
>
> hmmm as such there HAS to be a unique Id for evas's gl context anyway...
> and
> that text id will have to be unique as otherwise evas's context cant
> identify
> one texture from another... so this id is.. sufficient... is it not? :)
>

Yes i've realized that and wrote a response in another email.  I've handled
it in the patch
that I last sent.


>
> > > now as for target GL_TEXTURE_2D ... vs what?
> GL_TEXTURE_RECTANGLE_NV/ARB
> > > etc.?
> > > i'm not sure that's entirely wise? 1D and 3D textures would need proper
> > > handling then too. also rectangle textures are subject to a different
> > > coordinate space (in pixels vs 0.0 -> 1.0). right now the gl engine
> core
> > > doesn't use/handle these at all actually. i'm not entirely sure we need
> > > to/should as rectangle textures come with a whole bunch of
> > > gotchas/limitations,
> > > and there are standard npot textures around anyway. :) i'm not really
> sure
> > > any
> > > client would need/want to do this?
> >
> > the thought of having texture target came after seeing #ifdef
> > GL_TEXTURE_RECTANGLE_ARB
> > in the code.  If you tell the user that
> evas_object_image_native_surface_set
> > only
> > supports GL_TEXTURE_2D then I guess not having it would be fine.
>
> well that';s kind of "codd i might have implemented, but in reality it
> means
> dealing in 0.0->1.0 coords vs 0->N coords, and as its not universal, we
> need to
> do both.. and anyone that seems to do rectangle textures these days also
> handles npot textures. if they only do pow2 they seem to avoid rectangle
> textures"... so... i don't expect rect textures to be used... your
> thoughts?
>

I think it's fine.  rect textures are nice to use for multi-pass rendering
in my
opinion but, i think it's ok to assume regular texture  2D for now?


>
> > > so if you can fix the hash thing... that'd be good. the yinvert patch
> is
> > > already in svn, so just send an update on the other stuff as above :)
> > >
> > >
> > I'll do that once I get your response about the hash id.
>
> above :)
>


the last patch that i sent already has the above fixes so i'll apply the
other suggestions/comments that you have from the other email responses
before i send an updated patch.


> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas - OpenGL and Evas (Part 3)

[Sung W. Park]

On Fri, Mar 25, 2011 at 2:03 PM, Carsten Haitzler wrote:

> On Mon, 14 Mar 2011 16:54:00 +0900 "Sung W. Park" 
> said:
>
>
> > ok, i guess it's not a bad idea to keep track of the objects created via
> the
> > gl object
> > and delete them during evas_gl_free.
> >
> > now, i'm not sure if i'm using Eina properly here but would something
> like
> > this work?
> >
> > struct _Evas_GL
> > {
> >int magic;
> >Evas   *evas;
> >
> >Eina_List  *contexts;
> >Eina_List  *surfaces;
> > };
> >
> > .
> > EAPI void
> > evas_gl_free(Evas_GL *evas_gl)
> > {
> >Eina_List *l;
> >Evas_GL_Context *ctx;
> >Evas_GL_Surface *sfc;
> >
> >...
> >
> >// Delete undeleted surfaces
> >EINA_LIST_FOREACH(evas_gl->surfaces, l, sfc)
> >  {
> > if (sfc)
> >evas_gl_surface_destroy(evas_gl, sfc);
> >  }
> >...
> >
> >free(evas_gl);
> >evas_gl = NULL;
> > }
>
> no.. the way to do the  list free is more:
>
> while (evas_gl->surfaces)
>  evas_gl_surface_destroy(evas_gl, evas_gl->surfaces->data);
>
> (the surf destroy handles list removal for us so we know it'll remove the
> item
> we are looking at thus eventually draining the list to be empty)
>
>
sounds good. i'll go ahead and apply that.


> > EAPI void
> > evas_gl_surface_destroy(Evas_GL *evas_gl, Evas_GL_Surface *surf)
> > {
> >
> >...
> >
> >// Call Engine's Surface Destroy
> >
> > evas_gl->evas->engine.func->gl_surface_destroy
> > (evas_gl->evas->engine.data.output, surf->data);
> >
> >// Remove it from the list
> >evas_gl->surfaces = eina_list_remove(evas_gl->surfaces, surf);
> >
> >// Delete the object
> >free(surf);
> >surf = NULL;
> > }
> >
> > Thanks again!
> > Sung
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

i'm glad we got to this point =)

On Fri, Mar 25, 2011 at 2:59 PM, Carsten Haitzler wrote:

> On Wed, 16 Mar 2011 16:26:44 +0900 "Sung W. Park" 
> said:
>
> ok - accounting for some of the comments so far... her'es my take :)
> (finally)! :)
>
> 1. you use evas_object_image_pixels_dirty_set(). this is actually intended
> to
> work with the image pixel provider to ONLY provide new pixels IF the image
> is
> visible and needs drawing. it marks it dirty.. but won't call your pixel
> provider until render time and IF the object needs the new pixels. as such
> the
> timer_cb should JUST set the dirty flag and then in the pixel PROVIDER...
> call
> draw_gl(); at least then invisible objects would stop drawing themselevs
> and
> spining using cpu/gpu resources. :)
>
2.  just in general.. use animators.. not timers. timers is the "wrong" way
> to
> do animating. sure - they work, but animators all tick off at the same time
> at
> the same framerate :)
>

for 1 & 2, it was a quick fix to get the gears running.  with lack of
documentation
and all, it was a quick way to get them up and running. i'll take a look at
them.  =)


> 3. you allow a standard gl api to be used. glEnable(), glBegin() etc. etc.
> etc.
> - this is going to probably cause "symbol hell" and make it hard to wrap. i
> really thing all these should become something like:
>
> api = evas_gl_api_get();
>
> api->glEnable(...);
> api->glBegin();
> etc. etc.
>
> ie the evas_gl infra provides SPECIFIC calls you call - these may simply be
> the
> exact gl symbols exposed, or wrappers created by evas.
>
> another "Style" would be:
>
> evas_gl_glEnable(...);
> evas_gl_glBegin(...);
>
> ie expose 1 func in the evas api per gl func to wrap. this is less
> "dynamic"
> than the first one, but more "familiar".
>

I do prefer the first option and i actually have an API in the header that's
commented
out.  I was thinking that maybe we should start out with what I have there
and then progress
towards this direction.  Your thoughts?


> 4. the example include gl headers:
>
> e.g.:
> #include 
> #include 
>
> etc.
>
> as such i think Evas_GL.h should provide everything the app needs gl-wise
> in a
> portable way. they don't need top figure out gl vs gles etc. it also should
> just stick to the gles subset of gl (gles2 + some pre-made shaders to make
> it a
> bit more convenient like gles1.1 for fixed-function stuff).
>
> That's a good idea but I guess a user can be annoyed with not having the
standard
GL functions?  This would solve the glBindFramebuffer(...,0) issue though =)


> 5. what on earth are we going to do about runtime shader compiling? gles2
> problem. it may not provide shader compilers at runtime. shall we just
> agree to
> say "if your system doesnt provide runtime shader compiling, then it's
> insuffcient". ? what about shader binary readback? (store the compiled
> binary
> shader).
>
> i haven't had to deal with this issue so i don't know what would be the
best
approach but I think it's not a bad idea to say that it's insufficient =)

can you elaborate on the shader readback?

finally, how would you like me to proceed at this point?  I can make some of

the minor code changes that you've suggested earlier and submit another
set of patches for review and work progressively in terms of glapi and other
features.  let me know.

cheers,
Sung


>
> > Hi all,
> >
> > Based on the discussions and the comments that I've been getting, I'm
> > attaching
> > patches for the community to review and test out the code. The patches
> > implement
> > the code for the gl_x11 backend.  Other backends can be taken care of
> later
> > once this has been reviewed.
> >
> > I apologize if this patch seems a bit big.  I felt that we've had enough
> > discussions
> > on this topic already in increments and now we're at a point where we can
> > see this
> > prototype.
> >
> > Here are the description of the patches:
> > (by the way, apply the patches by giving -p0 from evas directory)
> >
> > 1. Evas_Engine_GL_Context.patch
> >   - Basically, this patch replaces all the instances of Evas_GL_Context
> used
> > by the gl engines to Evas_Engine_GL_Context.  This was changed
> because
> > Evas_GL_Context is exposed to the users by Evas_GL.h and this was
> ok'ed
> > in the previous discussion.
> >
> > 2. evas_gl.patch
> >   - This patch includes the image_object_native_surface_set() patch
> > since it's

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

Ok, i'm attaching the latest patch with the fixes discussed from the thread.

I'm attaching the following files.

1. evas_gl.patch
  - This patch includes the image_object_native_surface_set() patch
(I've added the code for hashing the image object.)
  - And, it has the rest of the code that allows evas_gl to run for gl_x11
engine.

2. Evas_GL.h
  - This files goes in
src/lib/

3. evas_gl.c
  - I've added the Evas magic check in evas_gl_new()
  - This files goes in
src/lib/canvas/

4. examples/
  - as discussed in the previous thread.  I've used the animator callback in
evasglgears.
  - i have tried using the image_pixel_get_callback_set as Carsten discussed
but I wasn't
getting any images out on Linux so I've commented it out for now.

Hopefully I've covered all the basis for this patch.
More to come in the near future hopefully.


On Tue, Mar 29, 2011 at 6:05 PM, Carsten Haitzler wrote:

> On Fri, 25 Mar 2011 17:28:48 +0900 "Sung W. Park" 
> said:
>
> > > On Wed, 16 Mar 2011 16:26:44 +0900 "Sung W. Park" 
> > > said:
> > >
> > > ok - accounting for some of the comments so far... her'es my take :)
> > > (finally)! :)
> > >
> > > 1. you use evas_object_image_pixels_dirty_set(). this is actually
> intended
> > > to
> > > work with the image pixel provider to ONLY provide new pixels IF the
> image
> > > is
> > > visible and needs drawing. it marks it dirty.. but won't call your
> pixel
> > > provider until render time and IF the object needs the new pixels. as
> such
> > > the
> > > timer_cb should JUST set the dirty flag and then in the pixel
> PROVIDER...
> > > call
> > > draw_gl(); at least then invisible objects would stop drawing
> themselevs
> > > and
> > > spining using cpu/gpu resources. :)
> > >
> > 2.  just in general.. use animators.. not timers. timers is the "wrong"
> way
> > > to
> > > do animating. sure - they work, but animators all tick off at the same
> time
> > > at
> > > the same framerate :)
> > >
> >
> > for 1 & 2, it was a quick fix to get the gears running.  with lack of
> > documentation
> > and all, it was a quick way to get them up and running. i'll take a look
> at
> > them.  =)
>
> sure!
>
> > > 3. you allow a standard gl api to be used. glEnable(), glBegin() etc.
> etc.
> > > etc.
> > > - this is going to probably cause "symbol hell" and make it hard to
> wrap. i
> > > really thing all these should become something like:
> > >
> > > api = evas_gl_api_get();
> > >
> > > api->glEnable(...);
> > > api->glBegin();
> > > etc. etc.
> > >
> > > ie the evas_gl infra provides SPECIFIC calls you call - these may
> simply be
> > > the
> > > exact gl symbols exposed, or wrappers created by evas.
> > >
> > > another "Style" would be:
> > >
> > > evas_gl_glEnable(...);
> > > evas_gl_glBegin(...);
> > >
> > > ie expose 1 func in the evas api per gl func to wrap. this is less
> > > "dynamic"
> > > than the first one, but more "familiar".
> > >
> >
> > I do prefer the first option and i actually have an API in the header
> that's
> > commented
> > out.  I was thinking that maybe we should start out with what I have
> there
> > and then progress
> > towards this direction.  Your thoughts?
>
> i think thats a good course. just clearing up what the final destination
> should
> be so everyone here sees/knows :)
>
> > > 4. the example include gl headers:
> > >
> > > e.g.:
> > > #include 
> > > #include 
> > >
> > > etc.
> > >
> > > as such i think Evas_GL.h should provide everything the app needs
> gl-wise
> > > in a
> > > portable way. they don't need top figure out gl vs gles etc. it also
> should
> > > just stick to the gles subset of gl (gles2 + some pre-made shaders to
> make
> > > it a
> > > bit more convenient like gles1.1 for fixed-function stuff).
> > >
> > > That's a good idea but I guess a user can be annoyed with not having
> the
> > standard
> > GL functions?  This would solve the glBindFramebuffer(...,0) issue though
> =)
>
> well it depends what "standard gl functions" they want. if we say "we do
> opengl-es2 subset AND then some extra functions as helpers to m

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

Hi,

On Mon, Apr 4, 2011 at 7:27 PM, Carsten Haitzler wrote:

> On Thu, 31 Mar 2011 23:02:09 +0900 "Sung W. Park" 
> said:
>
> i've had to fix a few things - but it's in svn now. it's not complete - for
> sure. btw. hint:


> export CFLAGS="-W -Wall -Wextra"
> :) beware the warnings! also .. for gl proc address getting.. i actually
> get
> the address.. of getprocaddress... i know. it's like checking you have your
> pants on after you've already walked out the front door... but i've
> encountered
> gl libs which dont have it... thus the dlsym fallback. :)
>

Great!  Yes, it's definitely not complete.  I'll try to tackle it one by one
as time permits.

Sorry about the Warnings.  I was a little surprised with the lack of
warnings when I
compiled the code.  haha...  the -W* flags somehow managed to evade my
attention. I
sorta assumed that they were in there.   my script has been fixed now =)

I see that you've fixed all the symbol warnings as well for the gl
extensions.  Thanks.


Ok, so I think it would be good to list items that we should work on here.
Here are
some of the things that come to mind.

1. Provide a subset of GL APIs in Evas_GL.h.  I guess we'll have to decide
on what to
include.  And then also think about a set of helper functions.

2. Integrate Evas_GL functionality to other engines. Software engine esp.?
- I think if we use Mesa, most of the GL code in the evas_engine.c in gl_x11
can be
reused even in the software backend.  Does that sound right?

3. Fix any necessary FIXME's in the code. =)

4. Implement an elm widget type of GLView library (but not an elm widget as
I think it's
unnecessary to make it an elm widget) that would help developers use for
simple GL rendering since EVAS GL is more low level.  I'm thinking a small
subset
of functions similar to what GLUT provides would be nice but this also needs
a round
of discussion.

Anything else?

Thanks again.

cheers,
Sung
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

[Sung W. Park]

Sounds good.  I'll go ahead and start working on getting the EVAS_GL_APIs
first then.

Before I get started on that though, I thought it would be good to get some
image_object
semantics straight.   I actually had to guess a lot of the image_object API
semantics
to get it running and I think it'll be good to figure all those things out
and also do some
thorough testing.

For example,

Currently, evas_object_image_data_get()  doesn't work if you use the
evas_object_image_native_surface_set() function to set a texture.
Should it actually return the texture data?

also, what about when you resize the data?  how is it supposed to behave if
it calls
evas_object_resize()?  it seems to repeat the texture pattern if it's bigger
than the
fill size that i initially give.  is that correct?

Any thoughts on what should work and which parts are ok for us to ignore?

Suggestions on how I should go about testing and getting the semantics right
would
be much appreciated.

thanks!
Sung



I've mentioned in my previous
email thread that you would have to create a


On Thu, Apr 7, 2011 at 1:33 PM, Carsten Haitzler wrote:

> On Tue, 5 Apr 2011 10:53:45 +0900 "Sung W. Park"  said:
>
> > Great!  Yes, it's definitely not complete.  I'll try to tackle it one by
> one
> > as time permits.
> >
> > Sorry about the Warnings.  I was a little surprised with the lack of
> > warnings when I
> > compiled the code.  haha...  the -W* flags somehow managed to evade my
> > attention. I
> > sorta assumed that they were in there.   my script has been fixed now =)
> >
> > I see that you've fixed all the symbol warnings as well for the gl
> > extensions.  Thanks.
>
> sometimes i feel nice  and do this :)
>
> > 
> >
> > Ok, so I think it would be good to list items that we should work on
> here.
> > Here are
> > some of the things that come to mind.
> >
> > 1. Provide a subset of GL APIs in Evas_GL.h.  I guess we'll have to
> decide
> > on what to
> > include.  And then also think about a set of helper functions.
>
> start with opengl-es2 calls and defined constants
>
> > 2. Integrate Evas_GL functionality to other engines. Software engine
> esp.?
> > - I think if we use Mesa, most of the GL code in the evas_engine.c in
> gl_x11
> > can be
> > reused even in the software backend.  Does that sound right?
>
> for context stuff - yes. for binding fbo. yes. BUT you'll need a way to get
> mesa's FBO ARGB pixel data to BE the pixel data of the image (same ARGB
> pixel
> format, same pointer etc.). that and fixing up mesa's gl symbols NOT to
> clash
> with a "real GL" via maybe dlopen(... RTLD_LOCAL); and literally stick
> those gl
> api calls in a separate table. how you may or may not get an FBO that mesa
> creates to become an evas image ARGB data (get access to the pointers
> themselves) beats me at this stage. this may require patches to mesa (or
> for
> mesa to USE evas's ARGB pixel pointer AS the FBO pixel data - the other way
> around). but it is possible as all the src for mesa is there.
>
> > 3. Fix any necessary FIXME's in the code. =)
>
> of course :)
>
> > 4. Implement an elm widget type of GLView library (but not an elm widget
> as
> > I think it's
> > unnecessary to make it an elm widget) that would help developers use for
> > simple GL rendering since EVAS GL is more low level.  I'm thinking a
> small
> > subset
> > of functions similar to what GLUT provides would be nice but this also
> needs
> > a round
> > of discussion.
>
> i'm up for this being an elm widget - it makes the most sense there. as for
> api
> that will turn up over time - like helpers from glut/glu etc. worlds...
> that
> will happen over time. to start implement just what's needed and build up
> from
> there.
>
> > Anything else?
> >
> > Thanks again.
> >
> > cheers,
> > Sung
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [Review] [Patch] Evas - OpenGL and Evas: eng_window_use (Bug Patch)

[Sung W. Park]

Hi all,

I've been toying around with creating a simple GLView smart object that
allows users do GL rendering simply.  Eventually, I would like to see this
as an Elementary widget called GLView.  The idea behind this is that
if evas_gl provides the low level stuff, GLView gives the simplified
user-version.
I'll start another email thread later on this topic.

The reason why I'm mentioning the above is because while working on GLView,
I've noticed an interesting behavior.  (You can see this by
compiling/running the
program that I'm attaching.)  I'm drawing a simple blended Triangle in
the middle
of the GLView object and what i'm getting is a smaller inverted red triangle on
the top left corner of the GLView object.  Obviously, something was messing
with the state of my GL code.

I've tracked this issue down to eng_window_use() in evas_x_main.c under gl_x11
module.  In the code,
_
void
eng_window_use(Evas_GL_X11_Window *gw)
{
   if ((_evas_gl_x11_window != gw) || (force_use))
 {
if (_evas_gl_x11_window)
  {
 evas_gl_common_context_use(_evas_gl_x11_window->gl_context);
 evas_gl_common_context_flush(_evas_gl_x11_window->gl_context);
  }
_evas_gl_x11_window = gw;
   if (gw)
 {
   
   // Make Current Stuff..
_

I've noticed that evas_gl_common_context_flush() gets called before it does
MakeCurrent().  When the evas_gl_common_context_flush() gets called, it resets
some shader stuff and does GL calls that tell the context to use the
particular shaders.  This explains why my GLView was picking on what seemed
to be the MVP matrix states that Evas was using.

Instead, what I think should happen is that the flush should be called after
MakeCurrent happens.  Otherwise, you're not guaranteeing that your GL calls are
being applied to the proper context. I've tried that and it seems to
address the
problem.

You can try running the glview program that I'm attaching before you apply
the patch and also try running it after you apply the patch.

Let me know if this seems reasonable or I'm missing something somewhere.

Thanks!

cheers,
Sung


glview.tgz
Description: GNU Zip compressed data
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas: eng_window_use (Bug Patch)

[Sung W. Park]

well, you're actually right.  I was a little concerned about that aspect but
now that you
point it out, it makes sense with multiple windows.

The real issue is that we have is evas_gl butting in and changing the
currrent context that evas isn't aware of.  the proper way to resolve
this would be for evas_gl_make_current to do a
evass_gl_common_context_flush().

the fix was a little hacky i admit..

I'll go ahead and fix evas_gl and send another patch.  =)

On Mon, Apr 18, 2011 at 3:50 PM, Carsten Haitzler wrote:

> On Wed, 13 Apr 2011 12:23:22 +0900 "Sung W. Park" 
> said:
>
> that patch seems wrong. if you are changing target window... and you have a
> previous window.. it flushes the gl render queue for the previous window
> target
> (or if the flush/use of the window) is flushed. you move the flush to AFTER
> setting the new context info (like new surfaces for read/write). that seems
> wrong.
>
> > Hi all,
> >
> > I've been toying around with creating a simple GLView smart object that
> > allows users do GL rendering simply.  Eventually, I would like to see
> this
> > as an Elementary widget called GLView.  The idea behind this is that
> > if evas_gl provides the low level stuff, GLView gives the simplified
> > user-version.
> > I'll start another email thread later on this topic.
> >
> > The reason why I'm mentioning the above is because while working on
> GLView,
> > I've noticed an interesting behavior.  (You can see this by
> > compiling/running the
> > program that I'm attaching.)  I'm drawing a simple blended Triangle in
> > the middle
> > of the GLView object and what i'm getting is a smaller inverted red
> triangle
> > on the top left corner of the GLView object.  Obviously, something was
> messing
> > with the state of my GL code.
> >
> > I've tracked this issue down to eng_window_use() in evas_x_main.c under
> gl_x11
> > module.  In the code,
> > _
> > void
> > eng_window_use(Evas_GL_X11_Window *gw)
> > {
> >if ((_evas_gl_x11_window != gw) || (force_use))
> >  {
> > if (_evas_gl_x11_window)
> >   {
> >  evas_gl_common_context_use(_evas_gl_x11_window->gl_context);
> >
>  evas_gl_common_context_flush(_evas_gl_x11_window->gl_context);
> >   }
> >   _evas_gl_x11_window = gw;
> >if (gw)
> >  {
> >
> >// Make Current Stuff..
> > _
> >
> > I've noticed that evas_gl_common_context_flush() gets called before it
> does
> > MakeCurrent().  When the evas_gl_common_context_flush() gets called, it
> resets
> > some shader stuff and does GL calls that tell the context to use the
> > particular shaders.  This explains why my GLView was picking on what
> seemed
> > to be the MVP matrix states that Evas was using.
> >
> > Instead, what I think should happen is that the flush should be called
> after
> > MakeCurrent happens.  Otherwise, you're not guaranteeing that your GL
> calls
> > are being applied to the proper context. I've tried that and it seems to
> > address the
> > problem.
> >
> > You can try running the glview program that I'm attaching before you
> apply
> > the patch and also try running it after you apply the patch.
> >
> > Let me know if this seems reasonable or I'm missing something somewhere.
> >
> > Thanks!
> >
> > cheers,
> > Sung
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas: eng_window_use (Bug Patch)

[Sung W. Park]

ok, i'm attaching a new patch.

the patch basically checks to see if the current context is evas' gl context
and if it is, it'll call evas_gl_common_context_flush().  I think this
is the proper
way to go.  :-)

cheers,
sung

On Mon, Apr 18, 2011 at 6:39 PM, Sung W. Park  wrote:
> well, you're actually right.  I was a little concerned about that aspect but
> now that you
> point it out, it makes sense with multiple windows.
> The real issue is that we have is evas_gl butting in and changing the
> currrent context that evas isn't aware of.  the proper way to resolve
> this would be for evas_gl_make_current to do a
> evass_gl_common_context_flush().
> the fix was a little hacky i admit..
> I'll go ahead and fix evas_gl and send another patch.  =)
> On Mon, Apr 18, 2011 at 3:50 PM, Carsten Haitzler 
> wrote:
>>
>> On Wed, 13 Apr 2011 12:23:22 +0900 "Sung W. Park" 
>> said:
>>
>> that patch seems wrong. if you are changing target window... and you have
>> a
>> previous window.. it flushes the gl render queue for the previous window
>> target
>> (or if the flush/use of the window) is flushed. you move the flush to
>> AFTER
>> setting the new context info (like new surfaces for read/write). that
>> seems
>> wrong.
>>
>> > Hi all,
>> >
>> > I've been toying around with creating a simple GLView smart object that
>> > allows users do GL rendering simply.  Eventually, I would like to see
>> > this
>> > as an Elementary widget called GLView.  The idea behind this is that
>> > if evas_gl provides the low level stuff, GLView gives the simplified
>> > user-version.
>> > I'll start another email thread later on this topic.
>> >
>> > The reason why I'm mentioning the above is because while working on
>> > GLView,
>> > I've noticed an interesting behavior.  (You can see this by
>> > compiling/running the
>> > program that I'm attaching.)  I'm drawing a simple blended Triangle in
>> > the middle
>> > of the GLView object and what i'm getting is a smaller inverted red
>> > triangle
>> > on the top left corner of the GLView object.  Obviously, something was
>> > messing
>> > with the state of my GL code.
>> >
>> > I've tracked this issue down to eng_window_use() in evas_x_main.c under
>> > gl_x11
>> > module.  In the code,
>> > _
>> > void
>> > eng_window_use(Evas_GL_X11_Window *gw)
>> > {
>> >    if ((_evas_gl_x11_window != gw) || (force_use))
>> >      {
>> >         if (_evas_gl_x11_window)
>> >           {
>> >
>> >  evas_gl_common_context_use(_evas_gl_x11_window->gl_context);
>> >
>> >  evas_gl_common_context_flush(_evas_gl_x11_window->gl_context);
>> >           }
>> >       _evas_gl_x11_window = gw;
>> >        if (gw)
>> >          {
>> >        
>> >        // Make Current Stuff..
>> > _
>> >
>> > I've noticed that evas_gl_common_context_flush() gets called before it
>> > does
>> > MakeCurrent().  When the evas_gl_common_context_flush() gets called, it
>> > resets
>> > some shader stuff and does GL calls that tell the context to use the
>> > particular shaders.  This explains why my GLView was picking on what
>> > seemed
>> > to be the MVP matrix states that Evas was using.
>> >
>> > Instead, what I think should happen is that the flush should be called
>> > after
>> > MakeCurrent happens.  Otherwise, you're not guaranteeing that your GL
>> > calls
>> > are being applied to the proper context. I've tried that and it seems to
>> > address the
>> > problem.
>> >
>> > You can try running the glview program that I'm attaching before you
>> > apply
>> > the patch and also try running it after you apply the patch.
>> >
>> > Let me know if this seems reasonable or I'm missing something somewhere.
>> >
>> > Thanks!
>> >
>> > cheers,
>> > Sung
>>
>>
>> --
>> - Codito, ergo sum - "I code, therefore I am" --
>> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>>
>
>
Index: src/modules/engines/gl_x11/evas_engine.c
===
--- src/modules/engines/gl_x11/evas_

[E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch

[Sung W. Park]

Hi all,

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.

Let me know what you guys think.

cheers,
Sung
Index: src/modules/engines/gl_x11/evas_engine.c
===
--- src/modules/engines/gl_x11/evas_engine.c	(revision 58768)
+++ src/modules/engines/gl_x11/evas_engine.c	(working copy)
@@ -2229,6 +2229,7 @@
Render_Engine *re;
Render_Engine_GL_Surface *sfc;
Evas_GL_Config *cfg; 
+   int ret;
 
sfc = calloc(1, sizeof(Render_Engine_GL_Surface));
 
@@ -2254,6 +2255,49 @@
 return NULL;
  }
 
+   // Create Render Target Texture/Buffers if not initialized
+   if (!sfc->initialized) 
+ {
+// 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)
+ret = eglMakeCurrent(re->win->egl_disp, re->win->egl_surface[0], re->win->egl_surface[0], re->win->egl_context[0]);
+#else
+ret = glXMakeCurrent(re->info->info.display, re->win->win, re->win->context);
+#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;
+  }
+
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ret = eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE, 
+ EGL_NO_SURFACE, EGL_NO_CONTEXT);
+#else
+ret = glXMakeCurrent(re->info->info.display, None, NULL);
+#endif
+if (!ret) 
+  {
+ ERR("xxxMakeCurrent() failed!");
+ free(sfc);
+ return 0;
+  }
+sfc->initialized = 1;
+ }
+
return sfc;
 }
 
@@ -2487,17 +2531,6 @@
 return 0;
  }
 
-   // Create Render Target Texture/Buffers if not initialized
-   if (!sfc->initialized) 
- {
-if (!_create_rt_buffers(re, sfc)) 
-  {
- ERR("_create_rt_buffers() failed.");
- return 0;
-  }
-sfc->initialized = 1;
- }
-
// Create FBO if not initalized already
if (!ctx->initialized) 
  {
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [Review] [Patch] Evas - evas_object_map_ y-invert case for Native Surface

[Sung W. Park]

Hi all,

As I was testing evas_gl, I've ran into a bug when I'm using the
evas_object_map_*
functions.

I don't necessarily want to say it's a bug because it did say
// FIXME: handle yinvert
ERR("not handling inverted y case for map");

So i'm submitting a patch that handles the yinvert case.

Index: src/modules/engines/gl_common/evas_gl_context.c
===
--- src/modules/engines/gl_common/evas_gl_context.c(revision 59024)
+++ src/modules/engines/gl_common/evas_gl_context.c(working copy)
@@ -2688,8 +2688,12 @@

if ((tex->im) && (tex->im->native.data) && (!tex->im->native.yinvert))
  {
-// FIXME: handle yinvert
-ERR("not handling inverted y case for map");
+for (i = 0; i < 4; i++)
+  {
+ ty[i] = 1.0 - ty[i];
+ if (yuv)
+t2y[i] = 1.0 - t2y[i];
+  }
  }

cmul = ARGB_JOIN(a, r, g, b);


I'm also submitting an example program that you can run to see before and
after.

let me know if this seems reasonable.

cheers,
Sung
Index: src/modules/engines/gl_common/evas_gl_context.c
===
--- src/modules/engines/gl_common/evas_gl_context.c	(revision 59024)
+++ src/modules/engines/gl_common/evas_gl_context.c	(working copy)
@@ -2688,8 +2688,12 @@
 
if ((tex->im) && (tex->im->native.data) && (!tex->im->native.yinvert))
  {
-// FIXME: handle yinvert
-ERR("not handling inverted y case for map");
+for (i = 0; i < 4; i++)
+  {
+ ty[i] = 1.0 - ty[i];
+ if (yuv)
+t2y[i] = 1.0 - t2y[i];
+  }
  }

cmul = ARGB_JOIN(a, r, g, b);
/**
 * Simple Evas_GL example
 */
#include 
#include 
#include 
#include 
// this gl include we won't need later when Evas_GL.h is complete
#include 

//static Evas_GL_API *evgl;

// demo - animator just to keep ticking over saying to draw the image
static Eina_Bool on_animate(void *data);

// callbacks we want to handle deletion on the object and updates/draws
static void on_pixels(void *data, Evas_Object *obj);
static void on_del(void *data, Evas *e, Evas_Object *obj, void *event_info);

int main(void)
{
   // config for the surface for evas_gl
   Evas_GL_Config config = 
 {
EVAS_GL_RGBA_8, 
EVAS_GL_DEPTH_NONE, 
EVAS_GL_STENCIL_NONE
 };
   // a size by default
   int w = 256, h = 256;
   // some variables we will use
   Ecore_Evas  *ee;
   Evas *canvas;
   Evas_Object *r1;
   Evas_Native_Surface ns;
   Evas_GL *evasgl;
   Evas_GL_Surface *sfc;
   Evas_GL_Context *ctx;
   float half_w, half_h;
   float degree;
   int x, y;
   Evas_Map *map;

   // regular low-leve EFL (ecore+ecore-evas) init. elm is simpler
   ecore_init();
   ecore_evas_init();
   ee = ecore_evas_gl_x11_new(NULL, 0, 0, 0, 512, 512);
   ecore_evas_title_set(ee, "Ecore_Evas Template");
   canvas = ecore_evas_get(ee);

   //-//-//-// THIS IS WHERE GL INIT STUFF HAPPENS (ALA EGL)
   //-//
   // get the evas gl handle for doing gl things
   evasgl = evas_gl_new(canvas);
   //evgl = evas_gl_api_get(evasgl);
   // create a surface and context 
   sfc = evas_gl_surface_create(evasgl, &config, w, h);
   ctx = evas_gl_context_create(evasgl, NULL);
   //-//
   //-//-//-// END GL INIT BLOB

   // set up the image object. a filled one by default
   r1 = evas_object_image_filled_add(canvas);
   // attach important data we need to the object using key names. this just
   // avoids some global variables and means we can do nice cleanup. you can
   // avoid this if you are lazy
   evas_object_data_set(r1, "..evasgl", evasgl);
   evas_object_data_set(r1, "..sfc", sfc);
   evas_object_data_set(r1, "..ctx", ctx);
   // when the object is deleted - call the on_del callback. like the above,
   // this is just being clean
   evas_object_event_callback_add(r1, EVAS_CALLBACK_DEL, on_del, NULL);
   // set up an actual pixel size fot the buffer data. it may be different
   // to the output size. any windowing system has something like this, just
   // evas has 2 sizes, a pixel size and the output object size
   evas_object_image_size_set(r1, w, h);
   // set up the native surface info to use the context and surface created
   // above
   //-//-//-// THIS IS WHERE GL INIT STUFF HAPPENS (ALA EGL)
   //evas_gl_make_current(evasgl, sfc, ctx);
   evas_gl_native_surface_get(evasgl, sfc, &ns);		
   evas_object_image_native_surface_set(r1, &ns);
   evas_object_image_pixels_get_callback_set(r1, on_pixels, r1);
   //-//
   //-//-//-// END GL INIT BLOB

   // move the image object somewhere, resize it and show it. any windowing
   // system would need this kind of thing - place a child "window"
   evas_object_move(r1, 128, 128);
   evas_object_resize(r1, w, h);


   map = evas_map_new(4);
   if (!map) return -1;

   evas_map_util_points_populate_from_object_full(map, r1, 0);
   degree = 30;

   evas_object_geometry_get(r1, &x, 

[E-devel] [Review] [Patch] Evas_GL minor fixes + FBO surface reattach bug fix

[Sung W. Park]

Hi all,

I'm attaching a patch for Evas_GL that fixes a few minor bugs.
For one, I had issues with stencil and depth format on OpenGL ES on a mobile
device using FBO.

Here's a part of the patch as an example...
(By the way, I'm covering 24bit format with 16bits on OpenGL ES for now... )

@@ -2112,7 +2113,12 @@
   case EVAS_GL_DEPTH_BIT_8:
   case EVAS_GL_DEPTH_BIT_16:
   case EVAS_GL_DEPTH_BIT_24:
+#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
  sfc->rb_depth_fmt = GL_DEPTH_COMPONENT;
+#endif
  break;
   case EVAS_GL_DEPTH_BIT_32:
   default:
@@ -2128,7 +2134,11 @@
   case EVAS_GL_STENCIL_BIT_2:
   case EVAS_GL_STENCIL_BIT_4:
   case EVAS_GL_STENCIL_BIT_8:
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ sfc->rb_stencil_fmt = GL_STENCIL_INDEX8;
+#else
  sfc->rb_stencil_fmt = GL_STENCIL_INDEX;
+#endif
  break;
   case EVAS_GL_STENCIL_BIT_16:
   default:
@@ -2180,14 +2190,13 @@
 }

Also, I've found a bug where deleting and recreating a surface wouldn't
properly reattach the surface with the FBO in the context.  So that has been
fixed here as well.

The fixes are in the file that I'm attaching: evas_gl_minor_fixes.patch

Also, I'm attaching an evasglgears.c that I've ported from glesgears.
It's still a bit messy but you can play around with it.  "left","right","up",
"down" button works as well. To compile the program, you just need to do

ECORE_PKG = `pkg-config --cflags --libs evas ecore ecore-evas`

evasglgears: evasglgears.c
gcc -g -Wall -o $@ $< $(ECORE_PKG) -lm

You no longer need to link -lGL if you haven't noticed already.

let me know if the patch seems reasonable.

cheers,
Sung
Index: src/modules/engines/gl_x11/evas_engine.c
===
--- src/modules/engines/gl_x11/evas_engine.c	(revision 59318)
+++ src/modules/engines/gl_x11/evas_engine.c	(working copy)
@@ -37,6 +37,7 @@
 struct _Render_Engine_GL_Surface
 {
int initialized;
+   int fbo_attached;
int w, h;
int depth_bits;
int stencil_bits;
@@ -2112,7 +2113,12 @@
   case EVAS_GL_DEPTH_BIT_8:
   case EVAS_GL_DEPTH_BIT_16:
   case EVAS_GL_DEPTH_BIT_24:
+#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
  sfc->rb_depth_fmt = GL_DEPTH_COMPONENT;
+#endif
  break;
   case EVAS_GL_DEPTH_BIT_32:
   default:
@@ -2128,7 +2134,11 @@
   case EVAS_GL_STENCIL_BIT_2:
   case EVAS_GL_STENCIL_BIT_4:
   case EVAS_GL_STENCIL_BIT_8:
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ sfc->rb_stencil_fmt = GL_STENCIL_INDEX8;
+#else
  sfc->rb_stencil_fmt = GL_STENCIL_INDEX;
+#endif
  break;
   case EVAS_GL_STENCIL_BIT_16:
   default:
@@ -2180,14 +2190,13 @@
 }
 
 static int
-_create_fbo_surface(Render_Engine *data __UNUSED__, 
+_attach_fbo_surface(Render_Engine *data __UNUSED__, 
 Render_Engine_GL_Surface *sfc, 
 Render_Engine_GL_Context *ctx)
 {
int fb_status;
 
// FBO
-   glGenFramebuffers(1, &ctx->fbo);
glBindFramebuffer(GL_FRAMEBUFFER, ctx->fbo);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
   GL_TEXTURE_2D, sfc->rt_tex, 0);
@@ -2221,16 +2230,6 @@
return 1;
 }
 
-/*
-static void
-eng_gl_options_set(void *data, int options __UNUSED__)
-{
-   Render_Engine *re;
-
-   re  = (Render_Engine *)data;
-}
-*/
-
 static void *
 eng_gl_surface_create(void *data, void *config, int w, int h)
 {
@@ -2247,6 +2246,7 @@
cfg = (Evas_GL_Config *)config;
 
sfc->initialized  = 0;
+   sfc->fbo_attached = 0;
sfc->w= w;
sfc->h= h;
sfc->depth_bits   = cfg->depth_bits;
@@ -2435,6 +2435,8 @@
 #endif
 
ctx->initialized = 0;
+   ctx->fbo = 0;
+   ctx->current_sfc = NULL;
 
return ctx;
 }
@@ -2509,6 +2511,7 @@
sfc = (Render_Engine_GL_Surface*)surface;
ctx = (Render_Engine_GL_Context*)context;
 
+   // Flush remainder of what's in Evas' pipeline
if (re->win)
  {
 #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
@@ -2528,6 +2531,7 @@
 #endif   
  }
 
+   // Unset surface/context
if ((!sfc) || (!ctx))
  {
 #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
@@ -2545,11 +2549,18 @@
 return ret;
  }
 
+   // Don't do a make current if it's already current
 #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
-   ret = eglMakeCurrent(re->win->egl_disp, re->win->egl_surface[0], 
-re->win->egl_surface[0], ctx->context);
+   if ((eglGetCurrentContext() != ctx->context))
+ {
+ 

[E-devel] [RFC] ELM GLView

[Sung W. Park]

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]

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 f

Re: [E-devel] [RFC] ELM GLView

[Sung W. Park]

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.  :)
>

[E-devel] [Patch] ELM GLView updates

[Sung W. Park]

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

[Sung W. Park]

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, t

Re: [E-devel] [Patch] Add override gl apis for osmesa

[Sung W. Park]

Silly mistake on my part.  Thanks for the report.
In SVN!

Thanks!
-Sung


2012/2/24 우승수 

>
> Dear All,
>
> When an application use glBindFramebuffer or glBindRenderbuffer via
> evas_gl after loding libosmesa.so,
> it shows segment fault.
>
> Because glBindFramebuffer and glBindRenderbuffer are not overrided.
> So, I fixed it.
>
> Thanks,
> Seungsoo
>
>
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: tasn IN trunk/evas/src: lib lib/canvas modules/engines/gl_x11

[Sung W. Park]

hmm... ok, I guess something went wrong somewhere.  I'll try a clean build
tomorrow before resubmitting it.

sorry about the trouble.

-Sung

On Wed, May 2, 2012 at 8:07 PM, Enlightenment SVN <
no-re...@enlightenment.org> wrote:

> Log:
> Revert "Cleaned up some evas_gl code and added surface cap feature."
>
>  This reverts commit 70617.
>
>  According to stefan_schmidt, reverting this fixes compilation errors.
>
> Author:   tasn
> Date: 2012-05-02 04:07:29 -0700 (Wed, 02 May 2012)
> New Revision: 70624
> Trac: http://trac.enlightenment.org/e/changeset/70624
>
> Modified:
>  trunk/evas/src/lib/Evas_GL.h trunk/evas/src/lib/canvas/evas_gl.c
> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>
> Modified: trunk/evas/src/lib/Evas_GL.h
> ===
> --- trunk/evas/src/lib/Evas_GL.h2012-05-02 10:54:14 UTC (rev 70623)
> +++ trunk/evas/src/lib/Evas_GL.h2012-05-02 11:07:29 UTC (rev 70624)
> @@ -2,6 +2,7 @@
>  #define _EVAS_GL_H
>
>  #include 
> +//#include 
>
>  #ifdef __cplusplus
>  extern "C" {
> @@ -421,11 +422,6 @@
>  * @param w The width of the surface.
>  * @param h The height of the surface.
>  * @return The created GL surface object, or NULL on failure.
> - *
> - * The surface_create function internally finds the closest surface
> - * configureation that matches the input config. The function then
> internally
> - * sets the input config parameters to the configuratoin that was actually
> - * used to create the surface.
>  */
>  EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL
> *evas_gl, Evas_GL_Config *cfg, int w, int h) EINA_WARN_UNUSED_RESULT
> EINA_ARG_NONNULL(1,2);
>
>
> Modified: trunk/evas/src/lib/canvas/evas_gl.c
> ===
> --- trunk/evas/src/lib/canvas/evas_gl.c 2012-05-02 10:54:14 UTC (rev 70623)
> +++ trunk/evas/src/lib/canvas/evas_gl.c 2012-05-02 11:07:29 UTC (rev 70624)
> @@ -39,7 +39,7 @@
>
>if (!evas_gl->evas->engine.func->gl_context_create)
>  {
> -ERR("Evas GL engine not available.");
> +ERR("GL engine not available\n");
> free(evas_gl);
> return NULL;
>  }
> @@ -96,7 +96,7 @@
>
>if (!config)
>  {
> -ERR("Invalid Config Pointer!");
> +ERR("Invalid Config\n");
> return NULL;
>  }
>
> @@ -108,7 +108,7 @@
>
>if (!surf->data)
>  {
> -ERR("Failed creating a surface from the engine.");
> +ERR("Failed creating a surface from the engine\n");
> free(surf);
> return NULL;
>  }
> @@ -129,7 +129,7 @@
>
>if (!surf)
>  {
> -ERR("Trying to destroy a NULL surface pointer!");
> +ERR("Trying to destroy a NULL surface pointer!\n");
> return;
>  }
>
> @@ -158,7 +158,7 @@
>ctx = calloc(1, sizeof(Evas_GL_Context));
>if (!ctx)
>  {
> -ERR("Unable to create a Evas_GL_Context object");
> +ERR("Unable to create a Evas_GL_Context object\n");
> return NULL;
>  }
>
> @@ -175,7 +175,7 @@
>// Set a few variables
>if (!ctx->data)
>  {
> -ERR("Failed creating a context from the engine.");
> +ERR("Failed creating a context from the engine\n");
> free(ctx);
> return NULL;
>  }
> @@ -197,7 +197,7 @@
>
>if (!ctx)
>  {
> -ERR("Trying to destroy a NULL context pointer!");
> +ERR("Trying to destroy a NULL context pointer!\n");
> return;
>  }
>
> @@ -256,12 +256,6 @@
>return EINA_FALSE;
>MAGIC_CHECK_END();
>
> -   if ((!surf) || (!ns))
> - {
> -ERR("Invalid input parameters!");
> -return EINA_FALSE;
> - }
> -
>return
> (Eina_Bool)evas_gl->evas->engine.func->gl_native_surface_get(evas_gl->evas->engine.data.output,
> surf->data, ns);
>  }
>
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-02
> 10:54:14 UTC (rev 70623)
> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-02
> 11:07:29 UTC (rev 70624)
> @@ -41,26 +41,17 @@
>int w, h;
>int vsync;
>
> -   // GL Surface Capability
> -   struct {
> -int rgb_fmt;
> -int rgba_fmt;
> +   // Shader used for Evas_GL_Direct Optimization
> +   GLuint   df_program;
> +   GLuint   df_vtx_shader;
> +   GLuint   df_fgmt_shader;
> +   GLuint   df_col_attrib;
> +   GLuint   df_pos_attrib;
>
> -int depth_8;
> -int depth_16;
> -int depth_24;
> -int depth_32;
> +   GLfloat  df_clear_color[4];
> +   GLfloat  df_depth_value;
>
> -int stencil_1;
> -int stencil_2;
> -int stencil_4;
> -int stencil_8;
> -int stencil_16;
> -
> -int depth_24_stencil_8;
> -   } gl_cap;
> -
> -   int gl_cap_initted;
> +   int  df_initialized;
>  };
>
>  struct _Render_Engine_

Re: [E-devel] [Patch]Enable multisampling capacity on the evasgl

[Sung W. Park]

Hi Sanghee,

I think we'll have to come up with a better way to differentiate between
Low,
Med, High in the future although...  I do recognize that the
GL_IMG_multisampled_render_to_texture isn't necessarily the best written GL
extension.  You can't exactly tell at what sample the driver is rendering.

Anyway, the patch looks fine and I've tested it on an EGL target to verify
that it
works.

In svn! Thanks for the patch.

cheers,
Sung


On Mon, May 14, 2012 at 2:22 PM, sanghee park  wrote:

> Dear all,
>
> I compose this mail to ask reviewal this patch about multisampling on the
> evasgl.
> I want to make multisampling capacity to enhance rendering quality of the
> evasgl.
> But if MSAA is applied always, this have possibility lowering rendering
> performance,
> I separated user's input level to high, mid, low, none.
> If you want to test this patch, try to examine rendering qulity on EGL
> circumstance with multisampling level.
> Plaese review it, and any suggestion will be appreciated.
>
> Best Regards,
> SangHee
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: sung IN trunk/evas: . src/lib src/modules/engines/gl_x11

[Sung W. Park]

Hi Vincent,

I didn't realize I was neglecting the NEWS.  I guess someone was covering
my rear all this time.  Thanks for getting the previous stuff in there to
whoever it was.  I'll get on it along with updating the Evas_GL. h.

Thanks for pointing that out.

cheers,
Sung

On Thu, May 17, 2012 at 6:46 AM, Vincent Torri wrote:

> missing doc for the new code in Evas_GL.h (don't forget @since)
>
> NEWS file, please
>
> Vincent
>
> On Mon, May 14, 2012 at 10:52 AM, Enlightenment SVN
>  wrote:
> > Log:
> > Adding MSAA (Multisample Anti-Aliased) Surface Option to Evas GL.
> >  Currently, this feature is only supported in EGL/GLESv2 environment
> >  with GL_IMG_multisampled_render_to_texture extension supported.
> >
> >  _
> >
> >  from:(sanghee park) sh15.p...@samsung.com
> >
> >  Dear all,
> >
> >   I compose this mail to ask reviewal this patch about multisampling
> on the evasgl.
> >   I want to make multisampling capacity to enhance rendering quality
> of the evasgl.
> >   But if MSAA is applied always, this have possibility lowering
> rendering performance,
> >   I separated user's input level to high, mid, low, none.
> >   If you want to test this patch, try to examine rendering qulity on
> EGL circumstance with multisampling level.
> >   Plaese review it, and any suggestion will be appreciated.
> >
> >   Best Regards,
> >   SangHee
> >
> >
> >
> >
> >
> >
> > Author:   sung
> > Date: 2012-05-14 01:52:56 -0700 (Mon, 14 May 2012)
> > New Revision: 70992
> > Trac: http://trac.enlightenment.org/e/changeset/70992
> >
> > Modified:
> >  trunk/evas/ChangeLog trunk/evas/src/lib/Evas_GL.h
> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> >
> > Modified: trunk/evas/ChangeLog
> > ===
> > --- trunk/evas/ChangeLog2012-05-14 08:21:48 UTC (rev 70991)
> > +++ trunk/evas/ChangeLog2012-05-14 08:52:56 UTC (rev 70992)
> > @@ -731,9 +731,15 @@
> >* Add CServe2 and image cache2 that makes use of it. Several
> changes
> >in the buffer and software engines to use the right cache if
> CServe2
> >is requested for the application.
> > -
> > +
> >  2012-05-14  Carsten Haitzler (The Rasterman)
> >
> > * Fix pixman rendering support if you set alpha flag AFTER
> > setting image size for custom image data.
> >
> > +2012-05-14 Sanghee Park
> > +
> > +   * Add Multisample Anti-Anliased surface format for Evas GL.
> > +The formats are divided into High, Med, Low, None, where High
> represent
> > +max number of samples.  Currently, this feature is only
> supported in GLES2
> > +environment with GL_IMG_multisampled_render_to_texture
> extension supported.
> >
> > Modified: trunk/evas/src/lib/Evas_GL.h
> > ===
> > --- trunk/evas/src/lib/Evas_GL.h2012-05-14 08:21:48 UTC (rev
> 70991)
> > +++ trunk/evas/src/lib/Evas_GL.h2012-05-14 08:52:56 UTC (rev
> 70992)
> > @@ -47,12 +47,21 @@
> >EVAS_GL_OPTIONS_DIRECT  = (1<<0)
> >  } Evas_GL_Options_Bits;
> >
> > +typedef enum _Evas_GL_Multisample_Bits
> > +{
> > +   EVAS_GL_MULTISAMPLE_NONE = 0,
> > +   EVAS_GL_MULTISAMPLE_LOW  = 1,
> > +   EVAS_GL_MULTISAMPLE_MED  = 2,
> > +   EVAS_GL_MULTISAMPLE_HIGH = 3
> > +} Evas_GL_Multisample_Bits;
> > +
> >  struct _Evas_GL_Config
> >  {
> > -   Evas_GL_Color_Format color_format;
> > -   Evas_GL_Depth_Bits   depth_bits;
> > -   Evas_GL_Stencil_Bits stencil_bits;
> > -   Evas_GL_Options_Bits options_bits;
> > +   Evas_GL_Color_Format   color_format;
> > +   Evas_GL_Depth_Bits depth_bits;
> > +   Evas_GL_Stencil_Bits   stencil_bits;
> > +   Evas_GL_Options_Bits   options_bits;
> > +   Evas_GL_Multisample_Bits   multisample_bits;
> >  };
> >
> >  #define EVAS_GL_EXTENSIONS   1
> > @@ -1122,6 +1131,12 @@
> >  #define GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG 0x8C02
> >  #define GL_COMPRESSED_RGBA_PVRTC_2BPPV1_IMG 0x8C03
> >
> > +/* GL_IMG_multisampled_render_to_texture */
> > +#define GL_RENDERBUFFER_SAMPLES_IMG 0x9133
> > +#define GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_IMG   0x9134
> > +#define GL_MAX_SAMPLES_IMG  0x9135
> > +#define GL_TEXTURE_SAMPLES_IMG  0x9136
> > +
> >
>  /**
> >  * NV extension tokens
> >
>  **/
> >
> > Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> > ===
> > --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-14
> 08:21:48 UTC (rev 70991)
> > +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-14
> 08:52:56 UT

Re: [E-devel] E SVN: sung trunk/evas/src/lib

[Sung W. Park]

yeah.. i don't like that kind of stuff either.  but as Carsten said, it was
out of necessity.  :-(

Sung

On Tue, May 22, 2012 at 8:39 AM, Carsten Haitzler wrote:

> On Mon, 21 May 2012 14:36:17 +0200 Vincent Torri 
> said:
>
> > On Mon, May 21, 2012 at 1:51 PM, Carsten Haitzler 
> > wrote:
> > > On Mon, 21 May 2012 10:04:06 +0200 Vincent Torri <
> vincent.to...@gmail.com>
> > > said:
> > >
> > > this code is actually right.
> >
> > i didn't say that it was wrong. I just said that i don't like that
> > kind of stuff.
>
> but in this situation its kind of a necessity to avoid "bizarre compile
> issues".
>
> > > evas_gl.h conflicts with gl headers - they are
> > > mutually exclusive since evas_gl is a one-stop shop for gl stuff when
> using
> > > it with evas1 - that includes all gl defines and so on.
> > >
> > >> i don't like that kind of stuff at all (not only your commit, but the
> > >> inclusion of specific gl headers).
> > >>
> > >> Vincent
> > >>
> > >> On Mon, May 21, 2012 at 10:01 AM, Enlightenment SVN
> > >>  wrote:
> > >> > Log:
> > >> > Separated checks for gl2.h defines and gl2ext.h defines in
> Evas_GL.h.
> > >> >
> > >> >
> > >> > Author:   sung
> > >> > Date: 2012-05-21 01:01:28 -0700 (Mon, 21 May 2012)
> > >> > New Revision: 71270
> > >> > Trac: http://trac.enlightenment.org/e/changeset/71270
> > >> >
> > >> > Modified:
> > >> >  trunk/evas/src/lib/Evas_GL.h
> > >> >
> > >> > Modified: trunk/evas/src/lib/Evas_GL.h
> > >> > ===
> > >> > --- trunk/evas/src/lib/Evas_GL.h2012-05-21 07:51:41 UTC (rev
> > >> > 71269) +++ trunk/evas/src/lib/Evas_GL.h2012-05-21 08:01:28
> UTC
> > >> > (rev 71270) @@ -1038,6 +1038,17 @@
> > >> >
> > >> >  #define GL_INVALID_FRAMEBUFFER_OPERATION  0x0506
> > >> >
> > >> > +#else
> > >> > +# ifndef EVAS_GL_NO_GL_H_CHECK
> > >> > +#  error "You may only include either Evas_GL.h OR use your native
> > >> > OpenGL's headers. If you use Evas to do GL, then you cannot use the
> > >> > native gl headers." +# endif +#endif
> > >> > +
> > >> > +
> > >> > +#if !defined(__glext_h_) && !defined(__gl2ext_h_)
> > >> > +# define __glext_h_
> > >> > +# define __gl2ext_h_
> > >> > +
> > >> >  //---//
> > >> >  // GLES extension defines
> > >> >
> > >> >
> > >> >
> > >> >
> --
> > >> > Live Security Virtual Conference
> > >> > Exclusive live event will cover all the ways today's security and
> > >> > threat landscape has changed and how IT managers can respond.
> Discussions
> > >> > will include endpoint security, mobile security and the latest in
> malware
> > >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > >> > ___
> > >> > enlightenment-svn mailing list
> > >> > enlightenment-...@lists.sourceforge.net
> > >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> > >>
> > >>
> --
> > >> Live Security Virtual Conference
> > >> Exclusive live event will cover all the ways today's security and
> > >> threat landscape has changed and how IT managers can respond.
> Discussions
> > >> will include endpoint security, mobile security and the latest in
> malware
> > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > >> ___
> > >> enlightenment-devel mailing list
> > >> enlightenment-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > >
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> --
> > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > >
> >
> >
> --
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.ac

[E-devel] [Review] [Patch] Evas_GL bug fixes/updates

[Sung W. Park]

Hi all,

I've fixed some minor issues that I've been pushing off for later.

The patch does the following:

1. Evas_GL and Evas had an issue where the viewport parameters were
being reset in the wrong context. Previously, this issue was temporarily
patched by flushing evas' pipeline and setting
evas_gl_common_context_use(NULL) in EvasGL's
make current. I know, it was pretty hacky. It turns out that in evas_engine,
there was a code evas_gl_common_context_resize(NULL) without doing
eng_window_use() first.  So i've added that part and problem went was
resolved properly. :-)

2. Naturally, I've taken out the temporary patch from 1.

3. I've added code that took care of glBindFramebuffer(..., fbo) where the
fbo had to be saved and restored in case the user wanted to use his own fbo.
Also, I've had to take care of the case when fbo is 0 since 0 need to point
to evas_gl surface.

4. I've updated make_current a little as well.

It's not that big of a patch.  let me know what you guys think.

cheers,
Sung


evas_gl_update.patch
Description: Binary data
--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [E-Devel][Patch] Eina TLS

[Sung W. Park]

Hi all,

I was in need of using thread local storage for some of the EvasGL stuff that
I'm currently working on. I've noticed that Eina doesn't have thread local
storage functions.  It would be best to simply use load-time TLS by using
__thread in Linux or __declspec(thread) in Windows in front of variables but
these two are not supported in all platforms that EFL supports.

You can check out what's supported in different platforms at this link below:

https://chtekk.longitekk.com/index.php?/archives/70-TLS-and-shared-library-initialization.html

So, I've decdied to add Eina APIs for run-time TLS support.

Here's an initial set of APIs that I've implemented.

static inline Eina_Bool eina_tls_new(Eina_TLS *key);
static inline void eina_tls_free(Eina_TLS key);
static inline void *eina_tls_get(Eina_TLS key);
static inline Eina_Bool eina_tls_set(Eina_TLS key, const void *data);

I didn't add destructor function pointer in eina_tls_new even though it's
supported in pthreads because they're not supported in windows.

I've tested the posix implmentation but I haven't been able to test the Windows
version.  If someone can review/test the code, that would be very helpful.

Let me know what you think.

cheers,
Sung
Index: src/include/eina_inline_lock_void.x
===
--- src/include/eina_inline_lock_void.x	(revision 64010)
+++ src/include/eina_inline_lock_void.x	(working copy)
@@ -215,6 +215,30 @@
return EINA_LOCK_FAIL;
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   return EINA_FALSE;
+}
+
+static inline void 
+eina_tls_free(Eina_TLS key)
+{
+}
+
+static inline void *
+eina_tls_get(Eina_TLS key)
+{
+   return NULL;
+}
+
+static inline Eina_Bool 
+eina_tls_set(Eina_TLS key, const void *data)
+{
+   return EINA_FALSE;
+}
+
+
 /**
  * @}
  */
Index: src/include/eina_inline_lock_win32.x
===
--- src/include/eina_inline_lock_win32.x	(revision 64010)
+++ src/include/eina_inline_lock_win32.x	(working copy)
@@ -433,4 +433,32 @@
return EINA_LOCK_SUCCEED;
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   if (TlsAlloc() == TLS_OUT_OF_INDEXES)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
+static inline void 
+eina_tls_free(Eina_TLS key)
+{
+   TlsFree(key);
+}
+
+static inline void *
+eina_tls_get(Eina_TLS key)
+{
+   return (void*)TlsGetValue(key);
+}
+
+static inline Eina_Bool 
+eina_tls_set(Eina_TLS key, const void *data)
+{
+   if (TlsSetValue(key, (LPVOID)data) == 0)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
 #endif
Index: src/include/eina_lock.h
===
--- src/include/eina_lock.h	(revision 64010)
+++ src/include/eina_lock.h	(working copy)
@@ -76,6 +76,12 @@
 static inline Eina_Lock_Result eina_rwlock_take_write(Eina_RWLock *mutex);
 static inline Eina_Lock_Result eina_rwlock_release(Eina_RWLock *mutex);
 
+static inline Eina_Bool eina_tls_new(Eina_TLS *key);
+static inline void eina_tls_free(Eina_TLS key);
+static inline void *eina_tls_get(Eina_TLS key);
+static inline Eina_Bool eina_tls_set(Eina_TLS key, const void *data);
+
+
 #ifdef EINA_HAVE_DEBUG_THREADS
 # define EINA_MAIN_LOOP_CHECK_RETURN_VAL(val)\
   do {	\
Index: src/include/eina_inline_lock_wince.x
===
--- src/include/eina_inline_lock_wince.x	(revision 64010)
+++ src/include/eina_inline_lock_wince.x	(working copy)
@@ -23,8 +23,9 @@
 
 EAPI extern Eina_Bool _threads_activated;
 
-typedef HANDLE Eina_Lock;
+typedef HANDLEEina_Lock;
 typedef Eina_Lock Eina_RWLock;
+typedef DWORD Eina_TLS;
 
 static inline Eina_Bool
 eina_lock_new(Eina_Lock *mutex)
@@ -144,4 +145,34 @@
return eina_lock_release(mutex);
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   if (TlsAlloc() == TLS_OUT_OF_INDEXES)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
+static inline void 
+eina_tls_free(Eina_TLS key)
+{
+   TlsFree(key);
+}
+
+static inline void *
+eina_tls_get(Eina_TLS key)
+{
+   return (void*)TlsGetValue(key);
+}
+
+static inline Eina_Bool 
+eina_tls_set(Eina_TLS key, const void *data)
+{
+   if (TlsSetValue(key, (LPVOID)data) == 0)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
+
+
 #endif
Index: src/include/eina_inline_lock_posix.x
===
--- src/include/eina_inline_lock_posix.x	(revision 64010)
+++ src/include/eina_inline_lock_posix.x	(working copy)
@@ -44,6 +44,7 @@
 typedef struct _Eina_Lock Eina_Lock;
 typedef struct _Eina_RWLock Eina_RWLock;
 typedef struct _Eina_Condition Eina_Condition;
+typedef pthread_key_t Eina_TLS;
 
 struct _Eina_Lock
 {
@@ -477,4 +478,32 @@
return EINA_LOCK_SUCCEED;
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   if (pthread_key_create(key, NULL) != 0)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
+stat

[E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly)

[Sung W. Park]

Hi all,

I'm submitting a patch that changes the color format for Evas GL.

When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8 and etc
but it was misleading for some people.  It was more of a filler since
I couldn't decide on
a name.  I'm finally changing it to make it more clear.

typedef enum _Evas_GL_Color_Format
{
EVAS_GL_RGB_888 = 0,  // 8 bits per channel
EVAS_GL_RGBA_ = 1
} Evas_GL_Color_Format;

typedef enum _Evas_GL_Depth_Bits
{
EVAS_GL_DEPTH_NONE   = 0,
EVAS_GL_DEPTH_BIT_8  = 1,
EVAS_GL_DEPTH_BIT_16 = 2,
EVAS_GL_DEPTH_BIT_24 = 3,
EVAS_GL_DEPTH_BIT_32 = 4,
} Evas_GL_Depth_Bits;

typedef enum _Evas_GL_Stencil_Bits
{
EVAS_GL_STENCIL_NONE   = 0,
EVAS_GL_STENCIL_BIT_1  = 1,
EVAS_GL_STENCIL_BIT_2  = 2,
EVAS_GL_STENCIL_BIT_4  = 3,
EVAS_GL_STENCIL_BIT_8  = 4,
EVAS_GL_STENCIL_BIT_16 = 5,
} Evas_GL_Stencil_Bits;

This will deal with backward compatibility issues as long as we keep the
ordering and the number same.

I'm also including an Elmentary patch for elm_glview.c that changes the format
accordingly.

Two patches:
   evas_gl_format_change.path// For Evas
   elmglview_evas_gl_format_change.patch   // For Elementary


Thanks a bunch.

cheers,
Sung
Index: src/lib/Evas_GL.h
===
--- src/lib/Evas_GL.h	(revision 64471)
+++ src/lib/Evas_GL.h	(working copy)
@@ -18,29 +18,27 @@
 
 typedef enum _Evas_GL_Color_Format
 {
-EVAS_GL_RGB_8,  // 8 bits per channel
-EVAS_GL_RGBA_8,
-EVAS_GL_RGB_32, // 32-bits per channel
-EVAS_GL_RGBA_32,
+EVAS_GL_RGB_888   = 0,
+EVAS_GL_RGBA_ = 1
 } Evas_GL_Color_Format;
 
 typedef enum _Evas_GL_Depth_Bits
 {
-EVAS_GL_DEPTH_BIT_8,
-EVAS_GL_DEPTH_BIT_16,
-EVAS_GL_DEPTH_BIT_24,
-EVAS_GL_DEPTH_BIT_32,
-EVAS_GL_DEPTH_NONE
+EVAS_GL_DEPTH_NONE   = 0,
+EVAS_GL_DEPTH_BIT_8  = 1,
+EVAS_GL_DEPTH_BIT_16 = 2,
+EVAS_GL_DEPTH_BIT_24 = 3,
+EVAS_GL_DEPTH_BIT_32 = 4,
 } Evas_GL_Depth_Bits;
 
 typedef enum _Evas_GL_Stencil_Bits
 {
-EVAS_GL_STENCIL_BIT_1,
-EVAS_GL_STENCIL_BIT_2,
-EVAS_GL_STENCIL_BIT_4,
-EVAS_GL_STENCIL_BIT_8,
-EVAS_GL_STENCIL_BIT_16,
-EVAS_GL_STENCIL_NONE
+EVAS_GL_STENCIL_NONE   = 0,
+EVAS_GL_STENCIL_BIT_1  = 1,
+EVAS_GL_STENCIL_BIT_2  = 2,
+EVAS_GL_STENCIL_BIT_4  = 3,
+EVAS_GL_STENCIL_BIT_8  = 4,
+EVAS_GL_STENCIL_BIT_16 = 5,
 } Evas_GL_Stencil_Bits;
 
 struct _Evas_GL_Config
@@ -98,7 +96,7 @@
// config for the surface for evas_gl
Evas_GL_Config config =
  {
-EVAS_GL_RGBA_8,
+EVAS_GL_RGBA_,
 EVAS_GL_DEPTH_NONE,
 EVAS_GL_STENCIL_NONE
  };
Index: src/modules/engines/gl_x11/evas_engine.c
===
--- src/modules/engines/gl_x11/evas_engine.c	(revision 64471)
+++ src/modules/engines/gl_x11/evas_engine.c	(working copy)
@@ -2778,20 +2778,14 @@
// Also initialize pixel format here as well...
switch(cfg->color_format)
  {
-  case EVAS_GL_RGB_8:
+  case EVAS_GL_RGB_888:
  sfc->rt_fmt  = GL_RGB;
  sfc->rt_internal_fmt = GL_RGB;
  break;
-  case EVAS_GL_RGBA_8:
+  case EVAS_GL_RGBA_:
  sfc->rt_fmt  = GL_RGBA;
  sfc->rt_internal_fmt = GL_RGBA;
  break;
-  case EVAS_GL_RGB_32:
- // Only supported on some hw
- // Fill it in later...
-  case EVAS_GL_RGBA_32:
- // Only supported on some hw
- // Fill it in later...
   default:
  ERR("Invalid Color Format!");
  return 0;
Index: src/lib/elm_glview.c
===
--- src/lib/elm_glview.c	(revision 64471)
+++ src/lib/elm_glview.c	(working copy)
@@ -219,7 +219,7 @@
Evas_Object *obj;
Evas *e;
Widget_Data *wd;
-   Evas_GL_Config cfg = { EVAS_GL_RGB_8,
+   Evas_GL_Config cfg = { EVAS_GL_RGB_888,
   EVAS_GL_DEPTH_NONE,
   EVAS_GL_STENCIL_NONE };
 
@@ -295,14 +295,14 @@
 {
ELM_CHECK_WIDTYPE(obj, widtype) EINA_FALSE;
Widget_Data *wd = elm_widget_data_get(obj);
-   Evas_GL_Config cfg = { EVAS_GL_RGBA_8,
+   Evas_GL_Config cfg = { EVAS_GL_RGBA_,
   EVAS_GL_DEPTH_NONE,
   EVAS_GL_STENCIL_NONE };
if (!wd) return EINA_FALSE;
 
// Set the configs
if (mode & ELM_GLVIEW_ALPHA)
- cfg.color_format = EVAS_GL_RGBA_8;
+ cfg.color_format = EVAS_GL_RGBA_;
 
if (mode & ELM_GLVIEW_DEPTH)
  cfg.depth_bits = EVAS_GL_DEPTH_BIT_24;
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certification

Re: [E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly)

[Sung W. Park]

wow, that was the fastest review/commit thus far! ;)  thanks!!

On Fri, Oct 28, 2011 at 8:08 PM, Carsten Haitzler wrote:

> On Fri, 28 Oct 2011 14:10:14 +0900 "Sung W. Park" 
> said:
>
> this one is in svn! approved. good! thanks muchly! :)
>
> > Hi all,
> >
> > I'm submitting a patch that changes the color format for Evas GL.
> >
> > When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8
> and
> > etc but it was misleading for some people.  It was more of a filler since
> > I couldn't decide on
> > a name.  I'm finally changing it to make it more clear.
> >
> > typedef enum _Evas_GL_Color_Format
> > {
> > EVAS_GL_RGB_888 = 0,  // 8 bits per channel
> > EVAS_GL_RGBA_ = 1
> > } Evas_GL_Color_Format;
> >
> > typedef enum _Evas_GL_Depth_Bits
> > {
> > EVAS_GL_DEPTH_NONE   = 0,
> > EVAS_GL_DEPTH_BIT_8  = 1,
> > EVAS_GL_DEPTH_BIT_16 = 2,
> > EVAS_GL_DEPTH_BIT_24 = 3,
> > EVAS_GL_DEPTH_BIT_32 = 4,
> > } Evas_GL_Depth_Bits;
> >
> > typedef enum _Evas_GL_Stencil_Bits
> > {
> > EVAS_GL_STENCIL_NONE   = 0,
> > EVAS_GL_STENCIL_BIT_1  = 1,
> > EVAS_GL_STENCIL_BIT_2  = 2,
> > EVAS_GL_STENCIL_BIT_4  = 3,
> > EVAS_GL_STENCIL_BIT_8  = 4,
> > EVAS_GL_STENCIL_BIT_16 = 5,
> > } Evas_GL_Stencil_Bits;
> >
> > This will deal with backward compatibility issues as long as we keep the
> > ordering and the number same.
> >
> > I'm also including an Elmentary patch for elm_glview.c that changes the
> format
> > accordingly.
> >
> > Two patches:
> >evas_gl_format_change.path// For Evas
> >elmglview_evas_gl_format_change.patch   // For Elementary
> >
> >
> > Thanks a bunch.
> >
> > cheers,
> > Sung
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-Devel][Review][Patch] Evas GL Fastpath

[Sung W. Park]

Hi Carsten,

That's really weird.  I've tested elementary_test before I submitted the
patch.
I'm wondering if there were changes that I made that would require
elementary recompile...  i can't think of one at the moment.

Just curious, are you using evas with NEWGL enabled?  If that's the case, it
explains the breakage.  My understanding was that NEWGL was broken and it
wasn't turned on by default so I didn't bother with it for now.

I'll try to track down the issue.

cheers,
Sung


On Sun, Nov 6, 2011 at 2:48 PM, Carsten Haitzler wrote:

> On Wed, 26 Oct 2011 14:08:47 +0900 "Sung W. Park" 
> said:
>
> > Hi all,
> >
> > I'm attaching a patch for the initial version of the GL Fastpath
> addition to
> > evas gl backend.
> >
> > Working on different mobile devices, we've noticed that the cost of
> context
> > switch (MakeCurrent) in GL can be very expensive depending on the driver
> > implementation.  To minimize the poorly written driver's context switch
> > overhead, I've implemented a state tracking layer on top of the driver
> > implemented GL.
> >
> > Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages
> its
> > own state changes.  Internally, only one real GL context is created and
> > logical contexts are created every time a user requests context creation.
> > The logical contexts keep track of its states and sets only the necessary
> > states (the ones that are different than the current ones)
> > when there is a MakeCurrent request.  The real MakeCurrent gets called
> when
> > there is a Surface/Window change request.
> >
> > The GL library is dlopened and all the APIs are dlsym'ed and wrapped
> > accordingly.  All the GL functions are in evas_gl_core.{h,c}.
> >
> > Here's a very simply flow of the code.
> >- all the APIs are exported as function pointers (*glsym_glBegin),
> >  (*glsm_eglCreatContext), and etc.
> >- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
> >  _sym_eglCreateContext, and etc.
> >- all the fastpath APIs are implmemnted as fpgl_glBegin,
> >  fpgl_eglCreateContext, and etc.
> >- if faspath is seletected, the exported APIs are set accordingly
> >  ie. glsym_glBegin = fpgl_glBegin;
> >- default mode is the regular gl symbols are directly set.
> >  ie. glsym_glBegin = _sym_glBegin;
> >
> > I have an Environment variable where you can set it to three different
> Modes
> >
> > EVAS_GL_FASTPATH = 0// Default mode. Regular GL symbols are directly
> > loaded EVAS_GL_FASTPATH = 1// Fastpath mode. Takes the path described
> > above. EVAS_GL_FASTPATH = 2// Wrapped mode.  All the regular GL
> functions
> > are wrapped once.  This can be used for various purposes
> >
> > Since all the GL symbols are now loaded in this library, I took out all
> > the gl symbol loading parts in the evas gl backend as you'll see in the
> patch.
> > The changes to the engine and the backend itself is pretty minor.
> >
> > There are still some known issues to hammer out but I thought we're at a
> good
> > place for an initial version so that my source doesn't diverge too much.
> >
> > Known Issues and To Do's
> > * Current GL Fastpath version doesn't support multiple threads.  Instead
> of
> >   having one global real context, I would need to do it for each thread.
> I'll
> >   get on this soon.
>
> this is.. unfortunately... important :( not currently, but in future it
> will be.
>
> > * Issues running Evas GL on certain conditions.  When running the
> elementary
> >   test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND
> > mode, everything works fine. BUT, when you run the ELMGLView test in
> ALWAYS
> >   mode, the subsequent elm tests shows blank screen. When you destroy the
> >   GLView window, everything else comes on fine.
>
> smells of a context tracking bug to me.
>
> > * Resource protection code.  This actually applies to Evas GL code in
> general
> >   as well. Since all the resources are shared among all the contexts
> that get
> >   created, I would like to eventually have a resource protecting
> mechanism
> > that prevents access to resources outside of its context unless
> specifically
> >   specified.
>
> how do you know which context a resource belongs to? eg a texture. afre you
> going to forbid 2 ctx's to set the same texture id as src texture for ops?
> sounds silly.
>
> > I'm attaching 

[E-devel] [E-Devel] Access

[Sung W. Park]

Hi all,

I've been working on Evas GL for some time now and I would like to request a
commit access.

I've been solely working on Evas_GL, elm_glview up until now and pretty much,
Raster has been the only person reviewing my code.

I'm at a point where having a commit access would make things a lot easier for
me and also benefit the community as well.

Here's what I've worked on and what I plan to work on.

- I've proposed the Evas_GL APIs as a way to do GL rendering in Evas and have
implemented the APIs for the runtime and the GL backend, both of which have
been upstreamed.
- I've also implemented an elementary widget called ELM GLView to make GL
rendring even simpler using elementary. Again, this has been applied upstream
as well.
- I have also worked on two key optimizations, both of which are streamlined
for review. One is called the GL Fastpath where I've implemented the state
tracking mechanism for GL drivers that have expensive context swtiches. Also,
I've implmented a direct rendering mechanism where if you turn on the
optimization hint on, it will render directly onto the Evas' X window whenever
possible.  (They still need to be refined but it's a good start in my opinion)
- I also have the Evas_GL software backend implemented but I haven't been
able to submit a patch for it yet due to other pending patches.
- I still need to write more test code and settle on the APIs once they've
been tested more by the community.
- Eventually, I would like to work more on Evas as well when the refactoring
takes place as I recognize along with Raster and others that it's about time
for anoter round of refactoring/rearchitecting the code.

Let me know if you have questions or concerns.

cheers,
Sung

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-Devel] Access

[Sung W. Park]

Awesome!  I look forward to working with you guys more closely as a
developer.  Thanks!

cheers,
Sung
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-Devel] Access

[Sung W. Park]

that's right!  better watch out for the fatality move~  ;-)

2011/12/21 ChunEon Park 

> Here comes new Mortal Kombat character!
> 
> -Regards, Hermet-
>
> -Original Message-----
> From: "Sung W. Park"<sung...@gmail.com>
> To: "Enlightenment developer list"&
> lt;enlightenment-devel@lists.sourceforge.net>
> Cc:
> Sent: 11-12-20(화) 16:08:20
> Subject: Re: [E-devel] [E-Devel] Access
> hi all,
> sorry this took so long. i got slammed with some bugs that i had to fix
> before I
> left for Hong Kong for a week to attend a conference. Now I'm back finally
> and
> ready to commit some code!
> I'm attaching the necessary files.
> looking forward working together with you guys~!
> by the way, that's a wig in the picture ;)
> cheers,
> Sung
> On Mon, Dec 5, 2011 at 11:37 AM, Sung W. Park <sung...@gmail.com>
> wrote:
> > Hi all,
> >
> > I've been working on Evas GL for some time now and I would like to
> request
> > a
> > commit access.
> >
> > I've been solely working on Evas_GL, elm_glview up until now and pretty
> > much,
> > Raster has been the only person reviewing my code.
> >
> > I'm at a point where having a commit access would make things a lot
> easier
> > for
> > me and also benefit the community as well.
> >
> > Here's what I've worked on and what I plan to work on.
> >
> > - I've proposed the Evas_GL APIs as a way to do GL rendering in Evas and
> > have
> > implemented the APIs for the runtime and the GL backend, both of which
> have
> > been upstreamed.
> > - I've also implemented an elementary widget called ELM GLView to make GL
> > rendring even simpler using elementary. Again, this has been applied
> > upstream
> > as well.
> > - I have also worked on two key optimizations, both of which are
> > streamlined
> > for review. One is called the GL Fastpath where I've implemented the
> state
> > tracking mechanism for GL drivers that have expensive context swtiches.
> > Also,
> > I've implmented a direct rendering mechanism where if you turn on the
> > optimization hint on, it will render directly onto the Evas' X window
> > whenever
> > possible. (They still need to be refined but it's a good start in my
> > opinion)
> > - I also have the Evas_GL software backend implemented but I haven't been
> > able to submit a patch for it yet due to other pending patches.
> > - I still need to write more test code and settle on the APIs once
> they've
> > been tested more by the community.
> > - Eventually, I would like to work more on Evas as well when the
> > refactoring
> > takes place as I recognize along with Raster and others that it's about
> > time
> > for anoter round of refactoring/rearchitecting the code.
> >
> > Let me know if you have questions or concerns.
> >
> > cheers,
> > Sung
> >
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>
> http://p.sf.net/sfu/intel-appdev___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster IN trunk/devs: . sung

[Sung W. Park]

does that mean I'm Spiderman?  ;-)

On Wed, Dec 21, 2011 at 7:24 PM, Daniel Juyung Seo wrote:

> Congratulations!
> With great power comes great responsibility.
>
> Daniel Juyung Seo (SeoZ)
>
> On Wed, Dec 21, 2011 at 6:30 PM, Enlightenment SVN
>  wrote:
> > Log:
> > sung++!
> >
> >
> >
> > Author:   raster
> > Date: 2011-12-21 01:30:04 -0800 (Wed, 21 Dec 2011)
> > New Revision: 66435
> > Trac: http://trac.enlightenment.org/e/changeset/66435
> >
> > Added:
> >  trunk/devs/sung/ trunk/devs/sung/icon-big.png
> trunk/devs/sung/icon-med.png trunk/devs/sung/icon-sml.png
> trunk/devs/sung/id_rsa.pub trunk/devs/sung/info.txt
> >
> >
> > Property changes on: trunk/devs/sung/icon-big.png
> > ___
> > Added: svn:mime-type
> >   + application/octet-stream
> >
> >
> > Property changes on: trunk/devs/sung/icon-med.png
> > ___
> > Added: svn:mime-type
> >   + application/octet-stream
> >
> >
> > Property changes on: trunk/devs/sung/icon-sml.png
> > ___
> > Added: svn:mime-type
> >   + application/octet-stream
> >
> >
> >
> --
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] E Korean diner before summer

[Sung W. Park]

i'll meet you guys at the restaurant! :)


On Sun, Jun 30, 2013 at 11:34 AM, Jérôme Pinot  wrote:

> On 06/30/13 01:43, Cedric BAIL wrote:
> > Yop,
> >
> > On Wed, Jun 26, 2013 at 5:09 AM, Cedric BAIL 
> wrote:
> > > On Wed, Jun 26, 2013 at 11:17 AM, Carsten Haitzler <
> ras...@rasterman.com> wrote:
> > >> On Wed, 26 Jun 2013 10:59:39 +0900 Jérôme Pinot 
> said:
> > >>> On 06/13/13 14:31, Cedric BAIL wrote:
> > >>> > Hello everyone,
> > >>> >
> > >>> > Who is in for a E-Dinner in Seoul on the 29 evening ? Maybe
> starting
> > >>> > in the afternoon.
> > >>> >
> > >>> > Have fun,
> > >>> > --
> > >>> > Cedric BAIL
> > >>>
> > >>> So the votes went mostly for sunday june 30 in Seoul:
> > >>> https://phab.enlightenment.org/V1
> > >>>
> > >>> Let's do it? At what time/place?
> > >>
> > >>
> https://maps.google.com/maps?q=Brick+Oven+New+York+Pizza+Gangnam+Seoul,+Gangnam-gu,+Seoul,+South+Korea&hl=en&ll=37.502913,127.027694&spn=0.00177,0.001971&sll=37.503283,127.028019&sspn=0.003541,0.003943&oq=gangnam+new+york&hq=Brick+Oven+New+York+Pizza+Gangnam+Seoul,&hnear=Gangnam-gu,+Seoul,+South+Korea&t=m&z=19&iwloc=A&layer=c&cbll=37.502999,127.02777&panoid=9RXWSeBE9zHCxRK9K4f8Jg&cbp=12,317.69,,0,-2.46
> > >
> > > We need to booked for that place. I am tasking JP for this as a
> > > homework :-) And maybe earlier we can go to some coffee place.
> >
> > Let's meet at 5pm in front of exit 11 of Gangnam station and we will
> > move from there.
> > --
> > Cedric BAIL
>
> OK for me!
>
> --
> Jérôme Pinot
> http://ngc891.blogdns.net/
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enventor (an edc editor prototype)

[Sung W. Park]

Looks really nice hermet! :)

what's wrong with 'enventor'???  it totally makes sense you know, like all
the other names.  i'm surprised that terminology wasn't name eterminology
;-)

cheers,
Sung


On Tue, Jul 23, 2013 at 10:52 AM, Carsten Haitzler wrote:

> On Tue, 23 Jul 2013 02:42:10 +0900 (KST) ChunEon Park 
> said:
>
> > http://www.youtube.com/watch?v=cOdgBBV4J3s&feature=youtu.be
>
> just call it inventor. enough of the "e" stuff. it sounds stupid to mangle
> words to stuff an e on the front. we have so much of it that people already
> can't keep track of what is what.
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

[Sung W. Park]

No problem. :)

I was worried that I would break something since I couldn't compile it but
it was simple a simple addition so I just went ahead with it.

For big ones, I'll let you know. :)

cheers,
Sung


On Tue, Jul 23, 2013 at 2:58 PM, Christopher Michael  wrote:

> Thank you for porting this !! :)
>
> Cheers,
> dh
>
> On 23/07/13 02:29, Sung W. Park - Enlightenment Git wrote:
> > sung pushed a commit to branch master.
> >
> > commit 7aa516c01a620da3438de864ac0c0e5b80c93d0b
> > Author: Sung W. Park 
> > Date:   Tue Jul 23 10:23:36 2013 +0900
> >
> >  Evas: adding image dump debug feature for wayland_egl backend
> >
> >  Porting commit f10c108283d9b76708418ba172b9ff0b28a09cd6 to wayland
> >  engine.
> >
> >  Added a feature to dump out a png image before calling SwapBuffers.
> >  To turn on the feature, use the following env vars.
> >
> >  EVAS_GL_SWAP_BUFFER_DEBUG_DIR="dir_name" sets the name of the
> directory
> >  that the files will be output to and enables the debug mode.
> >
> >  EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS=1 will enable the writing of the
> >  files every frame.  This in effect turns on the swap_buffer_debug
> >  variable, which can be set on or off in gdb for debugging.  This
> will
> >  allow dumping of certain frames without having to dump out a ton of
> >  files to track down one frame.
> > ---
> >   src/modules/evas/engines/wayland_egl/evas_engine.c | 43
> ++
> >   1 file changed, 43 insertions(+)
> >
> > diff --git a/src/modules/evas/engines/wayland_egl/evas_engine.c
> b/src/modules/evas/engines/wayland_egl/evas_engine.c
> > index 1db4dbd..65edcca 100644
> > --- a/src/modules/evas/engines/wayland_egl/evas_engine.c
> > +++ b/src/modules/evas/engines/wayland_egl/evas_engine.c
> > @@ -41,6 +41,7 @@ struct _Render_Engine
> >  Eina_Bool lost_back : 1;
> >  Eina_Bool end : 1;
> >  Eina_Bool evgl_initted : 1;
> > +   int   frame_cnt;
> >
> >  struct
> >{
> > @@ -103,6 +104,9 @@ static Eina_Bool extn_have_buffer_age = EINA_TRUE;
> >   static int safe_native = -1;
> >   static int partial_rect_union_mode = -1;
> >
> > +static int swap_buffer_debug_mode = -1;
> > +static int swap_buffer_debug = 0;
> > +
> >   /* function tables - filled in later (func and parent func) */
> >   static Evas_Func func, pfunc;
> >   static EVGL_Interface evgl_funcs =
> > @@ -1188,6 +1192,7 @@ static void
> >   eng_output_flush(void *data, Evas_Render_Mode render_mode)
> >   {
> >  Render_Engine *re;
> > +   static char *dname = NULL;
> >
> >  if (!(re = (Render_Engine *)data)) return;
> >
> > @@ -1201,6 +1206,41 @@ eng_output_flush(void *data, Evas_Render_Mode
> render_mode)
> >
> >  evas_gl_common_context_done(re->win->gl_context);
> >
> > +   // Save contents of the framebuffer to a file
> > +   if (swap_buffer_debug_mode == -1)
> > + {
> > +if ((dname = getenv("EVAS_GL_SWAP_BUFFER_DEBUG_DIR")))
> > +  {
> > + int stat;
> > + // Create a directory with 0775 permission
> > + stat = mkdir(dname,
> S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);
> > + if ((!stat) || errno == EEXIST) swap_buffer_debug_mode = 1;
> > +  }
> > +else
> > +   swap_buffer_debug_mode = 0;
> > + }
> > +
> > +   if (swap_buffer_debug_mode == 1)
> > + {
> > +// Set this env var to dump files every frame
> > +// Or set the global var in gdb to 1|0 to turn it on and off
> > +if (getenv("EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS"))
> > +   swap_buffer_debug = 1;
> > +
> > +if (swap_buffer_debug)
> > +  {
> > + char fname[100];
> > + int ret = 0;
> > + sprintf(fname, "%p", (void*)re->win);
> > +
> > + ret = evas_gl_common_buffer_dump(re->win->gl_context,
> > +  (const char*)dname,
> > +  (const char*)fname,
> > +  re->frame_cnt);
> > + if (!ret) swap_buffer_debug_mode = 0;
> > +  }
> > + }
> > +
> >  if (!re->vsync)
> >{
> >   if (re->info->vsync) eglSwapInterval(re->win->egl_disp, 1);
> > @@ 

Re: [E-devel] could somebody design Enventor logo?

[Sung W. Park]

actually the Cat's ass version is quite intriguing.  It could be an easter
egg..  =)


On Sun, Sep 1, 2013 at 11:10 AM, Murilo Belluzzo
wrote:

> Any chance to have --enable-debug using the "cat ass" icon version?
>
>
> On Fri, Aug 30, 2013 at 11:01 AM, Gustavo Lima Chaves
> wrote:
>
> > * Raoul Hecky  [2013-08-30 12:06:53 +0200]:
> >
> > > Happy? :)
> > > [image: Images intégrées 1]
> >
> > One word -- respect.
> >
> > >
> > > --
> > > Raoul Hecky
> > >
> > >
> > > 2013/8/30 Carsten Haitzler 
> > >
> > > > On Fri, 30 Aug 2013 09:58:15 +0200 Raoul Hecky <
> raoul.he...@gmail.com>
> > > > said:
> > > >
> > > > i have improved the icon.
> > > >
> > > > > Hi!
> > > > >
> > > > > I was bored this morning so I did one quickly... Is something like
> > that
> > > > > good for you?
> > > > > ;)
> > > > >
> > > > > [image: Images intégrées 1]
> > > > >
> > > > > --
> > > > > Raoul Hecky
> > > > >
> > > > >
> > > > > 2013/8/30 Carsten Haitzler 
> > > > >
> > > > > > On Fri, 30 Aug 2013 15:12:16 +0900 (KST) ChunEon Park <
> > > > her...@naver.com>
> > > > > > said:
> > > > > >
> > > > > > https://i.chzbgr.com/maxW500/4528375296/h81227BB3/
> > > > > >
> > > > > > > Could somebody design Enventor logo gladly?
> > > > > > >
> > > > > > > I'm not a professional for design as well as im  poor at deisn
> > tool.
> > > >  :-3
> > > > > > >
> > > > > > > I hope you help me If you have talent for design.
> > > > > > >
> > > > > > > 
> > > > > > > -Regards, Hermet-
> > > > > > >
> > > > > >
> > > >
> >
> --
> > > > > > > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL
> 2012,
> > > > more!
> > > > > > > Discover the easy way to master current and previous Microsoft
> > > > > > technologies
> > > > > > > and advance your career. Get an incredible 1,500+ hours of
> > > > step-by-step
> > > > > > > tutorial videos with LearnDevNow. Subscribe today and save!
> > > > > > >
> > > > > >
> > > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> > > > > > > ___
> > > > > > > enlightenment-devel mailing list
> > > > > > > enlightenment-devel@lists.sourceforge.net
> > > > > > >
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > - Codito, ergo sum - "I code, therefore I am"
> > > > --
> > > > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
> --
> > > > > > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012,
> > more!
> > > > > > Discover the easy way to master current and previous Microsoft
> > > > technologies
> > > > > > and advance your career. Get an incredible 1,500+ hours of
> > step-by-step
> > > > > > tutorial videos with LearnDevNow. Subscribe today and save!
> > > > > >
> > > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> > > > > > ___
> > > > > > enlightenment-devel mailing list
> > > > > > enlightenment-devel@lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > > >
> > > >
> > > >
> > > > --
> > > > - Codito, ergo sum - "I code, therefore I am"
> > --
> > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > > >
> > > >
> >
> >
> >
> > >
> >
> --
> > > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> > > Discover the easy way to master current and previous Microsoft
> > technologies
> > > and advance your career. Get an incredible 1,500+ hours of step-by-step
> > > tutorial videos with LearnDevNow. Subscribe today and save!
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> >
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> > --
> > Gustavo Lima Chaves
> > Senior Developer @ Intel - Open Source Technology Center
> >
> >
> >
> --
> > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> > Discover the easy way to master current and previous Microsoft
> technologies
> > and advance your career. Get an incredible 1,500+ hours of step-by-step
> > tutorial videos with LearnDevNow. Subscribe today and save!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.s

[E-devel] Building efl on Mac OSX

[Sung W. Park]

Hi all,

Has any of you tried compiling efl on Mac lately?

I've followed the Wiki page instructions before efl was merged to a single
tree and got it to work but now I've just tried it again last night and I'm
getting the following errors.

  CC   lib/ecore/lib_ecore_libecore_la-ecore_coroutine.lo
lib/ecore/ecore_coroutine.c: In function '_ecore_coroutine_setjmp':
lib/ecore/ecore_coroutine.c:124: error: request for member 'env' in
something not a structure or union
lib/ecore/ecore_coroutine.c:125: error: request for member 'env' in
something not a structure or union
lib/ecore/ecore_coroutine.c: In function 'ecore_coroutine_resume':
lib/ecore/ecore_coroutine.c:282: error: incompatible types in assignment
lib/ecore/ecore_coroutine.c:289: error: too few arguments to function
'longjmp'
lib/ecore/ecore_coroutine.c:293: error: incompatible types in assignment
lib/ecore/ecore_coroutine.c:295: error: incompatible types in assignment
lib/ecore/ecore_coroutine.c: In function 'ecore_coroutine_yield':
lib/ecore/ecore_coroutine.c:310: error: too few arguments to function
'longjmp'

Obviously this is all Cedric's doing as all bugs and errors come from him
;-) but I was just wondering if any of you guys tried it on Mac lately.

cheers,
Sung
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Building efl on Mac OSX

[Sung W. Park]

Great! :)

-Sung


On Sun, Sep 15, 2013 at 5:00 AM, Leif Middelschulte <
leif.middelschu...@gmail.com> wrote:

> Am Samstag, 14. September 2013 um 18:05 schrieb Stefan Schmidt:
> > Hello.
> >
> > On Sat, 2013-09-14 at 17:21, Leif Middelschulte wrote:
> > > Am Samstag, 14. September 2013 um 17:16 schrieb Sung W. Park:
> > > > Hi all,
> > > >
> > > > Has any of you tried compiling efl on Mac lately?
> > > >
> > > > I've followed the Wiki page instructions before efl was merged
> > > > to a single tree and got it to work but now I've just tried it
> > > > again last night and I'm getting the following errors.
> > > >
> > > > CC lib/ecore/lib_ecore_libecore_la-ecore_coroutine.lo
> > > > lib/ecore/ecore_coroutine.c: In function
> > > > '_ecore_coroutine_setjmp': lib/ecore/ecore_coroutine.c:124:
> > > > error: request for member 'env' in something not a structure or
> > > > union lib/ecore/ecore_coroutine.c:125: error: request for member
> > > > 'env' in something not a structure or union
> > > > lib/ecore/ecore_coroutine.c: In function
> > > > 'ecore_coroutine_resume': lib/ecore/ecore_coroutine.c:282:
> > > > error: incompatible types in assignment
> > > > lib/ecore/ecore_coroutine.c:289: error: too few arguments to
> > > > function 'longjmp' lib/ecore/ecore_coroutine.c:293: error:
> > > > incompatible types in assignment
> > > > lib/ecore/ecore_coroutine.c:295: error: incompatible types in
> > > > assignment lib/ecore/ecore_coroutine.c: In function
> > > > 'ecore_coroutine_yield': lib/ecore/ecore_coroutine.c:310: error:
> > > > too few arguments to function 'longjmp'
> > > >
> > > > Obviously this is all Cedric's doing as all bugs and errors come
> > > > from him ;-) but I was just wondering if any of you guys tried
> > > > it on Mac lately.
> > > >
> > >
> > >
> > > Hey,
> > >
> > > actually, I'm waiting for the 1.8 release of efl to provide
> > > recipes for the Mac OS packager manager Homebrew. So I'm not
> > > bothering until the release happens.
> > >
> >
> >
> > Which means it might, or in this case will, be broken for the
> > release and only discovered afterwards. Everyone who cares about a
> > specific distributions, architecture or setup should test _before_ a
> > release so this can be fixed and working once the release is due.
> >
> >
>
> Sure,
>
> if the release of 1.8 is at least in sight, I might give it (packaging)
> another shot ;-)
>
> regards,
>
> Leif
> >
> > regards
> > Stefan Schmidt
> >
> >
> --
> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net (mailto:
> enlightenment-devel@lists.sourceforge.net)
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
>
>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: Evas: EGL-GL backends. Call eglReleaseThread() upon shutdown

[Sung W . Park]

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=56e71e05bb39b90f71f5bfdedcc8211c542ee176

commit 56e71e05bb39b90f71f5bfdedcc8211c542ee176
Author: Sung W. Park 
Date:   Mon Oct 14 14:33:25 2013 +0900

Evas: EGL-GL backends. Call eglReleaseThread() upon shutdown

Call proper cleanup code upon terminating egl use.
---
 src/modules/evas/engines/gl_x11/evas_x_main.c   | 1 +
 src/modules/evas/engines/wayland_egl/evas_wl_main.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/modules/evas/engines/gl_x11/evas_x_main.c 
b/src/modules/evas/engines/gl_x11/evas_x_main.c
index 1b78d4c..1a088ab 100644
--- a/src/modules/evas/engines/gl_x11/evas_x_main.c
+++ b/src/modules/evas/engines/gl_x11/evas_x_main.c
@@ -437,6 +437,7 @@ eng_window_free(Evas_GL_X11_Window *gw)
  {
 if (context) eglDestroyContext(gw->egl_disp, context);
 eglTerminate(gw->egl_disp);
+eglReleaseThread();
 context = EGL_NO_CONTEXT;
  }
 #else
diff --git a/src/modules/evas/engines/wayland_egl/evas_wl_main.c 
b/src/modules/evas/engines/wayland_egl/evas_wl_main.c
index 7efbb41..4c49570 100644
--- a/src/modules/evas/engines/wayland_egl/evas_wl_main.c
+++ b/src/modules/evas/engines/wayland_egl/evas_wl_main.c
@@ -212,6 +212,7 @@ eng_window_free(Evas_GL_Wl_Window *gw)
  {
 if (context) eglDestroyContext(gw->egl_disp, context);
 eglTerminate(gw->egl_disp);
+eglReleaseThread();
 context = EGL_NO_CONTEXT;
  }
 

-- 

[EGIT] [core/efl] master 01/01: EvasGL: Fixed direct rendering not clipping issue

[Sung W . Park]

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=7dc102c55f6de2a9952cf79ffa69b50ab66df4c1

commit 7dc102c55f6de2a9952cf79ffa69b50ab66df4c1
Author: Sung W. Park 
Date:   Thu Oct 24 17:37:22 2013 +0900

EvasGL: Fixed direct rendering not clipping issue

Evas GL direct rendering mode didn't properly take into account
the image object's clipping information and clip the region that
it was directly rendering to. Hence there were issues with the
direct rendering region drawing over the objects that are sitting
on top of it.

Also, cleaned up the direct rendering coordinate computation code
and a nasty dependency with image object that should have been
removed a long time ago.  Basically the evas-gl engine was directly
accessing the image object data structure for its data when it
really should have just passed along necessary information.
---
 ChangeLog  |   3 +
 src/modules/evas/engines/gl_common/evas_gl_api.c   | 231 +
 src/modules/evas/engines/gl_common/evas_gl_core.c  |  76 +--
 src/modules/evas/engines/gl_common/evas_gl_core.h  |  39 ++--
 .../evas/engines/gl_common/evas_gl_core_private.h  |  25 ++-
 src/modules/evas/engines/gl_x11/evas_engine.c  |  33 ++-
 src/modules/evas/engines/wayland_egl/evas_engine.c |  21 +-
 7 files changed, 237 insertions(+), 191 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d952a22..c5042ad 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,6 @@
+2013-10-24  Sung W. Park (sung_)
+* EvasGL: Fixed direct rendering mode not clipping to its clip region.
+
 2013-10-18  Youngbok Shin
 
 * Fixed the textblock format to be drawn according to
diff --git a/src/modules/evas/engines/gl_common/evas_gl_api.c 
b/src/modules/evas/engines/gl_common/evas_gl_api.c
index 968f7e1..6b93548 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_api.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_api.c
@@ -20,7 +20,7 @@ void _make_current_check(const char* api)
 
if (!ctx)
  {
-CRIT("\e[1;33m%s\e[m: Current Context NOT SET: GL Call Should NOT Be 
Called without MakeCurrent!!!", api); 
+CRIT("\e[1;33m%s\e[m: Current Context NOT SET: GL Call Should NOT Be 
Called without MakeCurrent!!!", api);
  }
 }
 
@@ -157,45 +157,23 @@ _evgl_glReleaseShaderCompiler(void)
 // returns: objc[4] (nc[4]) tranformed  (x, y, width, heigth) in gl coord
 // returns: cc[4] cliped coordinate in original coordinate
 static void
-compute_gl_coordinates(Evas_Object *obj, int rot, int clip_image,
+compute_gl_coordinates(int win_w, int win_h, int rot, int clip_image,
int x, int y, int width, int height,
-   int clip[4],
+   int img_x, int img_y, int img_w, int img_h,
+   int clip_x, int clip_y, int clip_w, int clip_h,
int imgc[4], int objc[4], int cc[4])
 {
-   Evas_Object_Protected_Data *pd = eo_data_scope_get(obj, EVAS_OBJ_CLASS);
-
-   int obj_x, obj_y, obj_w, obj_h;
-   int clip_x, clip_y, clip_w, clip_h;
-   int out_w, out_h;
-
-   // Original Coordinates
-   obj_x = pd->cur->geometry.x;
-   obj_y = pd->cur->geometry.y;
-   obj_w = pd->cur->geometry.w;
-   obj_h = pd->cur->geometry.h;
-
-   // Clip Region
-   clip_x = clip[0];
-   clip_y = clip[1];
-   clip_w = clip[2];
-   clip_h = clip[3];
-
-   // Output Window Size
-   out_w = pd->layer->evas->output.w;
-   out_h = pd->layer->evas->output.h;
-
-
if (rot == 0)
  {
 // oringinal image object coordinate in gl coordinate
-imgc[0] = obj_x;
-imgc[1] = out_h - obj_y - obj_h;
-imgc[2] = imgc[0] + obj_w;
-imgc[3] = imgc[1] + obj_h;
+imgc[0] = img_x;
+imgc[1] = win_h - img_y - img_h;
+imgc[2] = imgc[0] + img_w;
+imgc[3] = imgc[1] + img_h;
 
 // clip coordinates in gl coordinate
 cc[0] = clip_x;
-cc[1] = out_h - clip_y - clip_h;
+cc[1] = win_h - clip_y - clip_h;
 cc[2] = cc[0] + clip_w;
 cc[3] = cc[1] + clip_h;
 
@@ -208,20 +186,20 @@ compute_gl_coordinates(Evas_Object *obj, int rot, int 
clip_image,
else if (rot == 180)
  {
 // oringinal image object coordinate in gl coordinate
-imgc[0] = out_w - obj_x - obj_w;
-imgc[1] = obj_y;
-imgc[2] = imgc[0] + obj_w;
-imgc[3] = imgc[1] + obj_h;
+imgc[0] = win_w - img_x - img_w;
+imgc[1] = img_y;
+imgc[2] = imgc[0] + img_w;
+imgc[3] = imgc[1] + img_h;
 
 // clip coordinates in gl coordinate
-cc[0] = out_w - clip_x - clip_w;
+cc[0] = win_w - clip_x - clip_w;
 cc[1] = clip_y;
 cc[2] = cc[0] + clip_w;
 cc[3] = cc[1] + clip_h;
 
 // transformed (x,y,width,height) in gl coordinate
-objc[

[EGIT] [core/efl] master 01/01: EvasGL: cleaning up unnecessary code.

[Sung W . Park]

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=9bb4c4869199118d9d16c87edc5084e8d1d49fb7

commit 9bb4c4869199118d9d16c87edc5084e8d1d49fb7
Author: Sung W. Park 
Date:   Wed Oct 30 10:47:52 2013 +0900

EvasGL: cleaning up unnecessary code.

Cleaning up unnecessary code.
---
 src/modules/evas/engines/gl_common/evas_gl_core.c  | 50 --
 src/modules/evas/engines/gl_common/evas_gl_core.h  |  7 ---
 .../evas/engines/gl_common/evas_gl_core_private.h  |  1 -
 3 files changed, 58 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.c 
b/src/modules/evas/engines/gl_common/evas_gl_core.c
index a065bd4..e5009cd 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.c
@@ -1869,38 +1869,6 @@ evgl_direct_info_clear()
rsc->direct.enabled = EINA_FALSE;
 }
 
-/*
-void
-evgl_direct_img_obj_set(Evas_Object *img, int rot)
-{
-   EVGL_Resource *rsc;
-
-   if (!(rsc=_evgl_tls_resource_get())) return;
-
-   // Normally direct rendering isn't allowed if alpha is on and
-   // rotation is not 0.  BUT, if override is on, allow it.
-   if (rot!=0)
- {
-if (evgl_engine->direct_override)
-   rsc->direct.img = img;
-else
-   rsc->direct.img = NULL;
- }
-   else
-  rsc->direct.img = img;
-}
-
-Evas_Object *
-evgl_direct_img_obj_get()
-{
-   EVGL_Resource *rsc;
-
-   if (!(rsc=_evgl_tls_resource_get())) return NULL;
-
-   return rsc->direct.img;
-}
-*/
-
 Evas_GL_API *
 evgl_api_get()
 {
@@ -1909,24 +1877,6 @@ evgl_api_get()
return &gl_funcs;
 }
 
-
-/*
-void
-evgl_direct_img_clip_set(int c, int x, int y, int w, int h)
-{
-   EVGL_Resource *rsc;
-
-   if (!(rsc=_evgl_tls_resource_get())) return;
-
-   rsc->master_clip = c;
-   rsc->clip[0] = x;
-   rsc->clip[1] = y;
-   rsc->clip[2] = w;
-   rsc->clip[3] = h;
-
-}
-*/
-
 void
 evgl_direct_override_get(int *override, int *force_off)
 {
diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.h 
b/src/modules/evas/engines/gl_common/evas_gl_core.h
index bbd5b24..587e8b0 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.h
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.h
@@ -33,16 +33,9 @@ int  evgl_native_surface_get(EVGL_Surface *sfc, 
Evas_Native_Surface *ns)
 Evas_GL_API *evgl_api_get();
 int  evgl_direct_rendered();
 
-
-/*
-extern void evgl_direct_img_obj_set(Evas_Object *img, int rot);
-extern Evas_Object *evgl_direct_img_obj_get();
-*/
-
 void evgl_direct_info_set(int win_w, int win_h, int rot, int img_x, 
int img_y, int img_w, int img_h, int clip_x, int clip_y, int clip_w, int 
clip_h);
 void evgl_direct_info_clear();
 
-//extern void evgl_direct_img_clip_set(int c, int x, int y, int w, int 
h);
 void evgl_direct_override_get(int *override, int *force_off);
 
 #endif //_EVAS_GL_CORE_H
diff --git a/src/modules/evas/engines/gl_common/evas_gl_core_private.h 
b/src/modules/evas/engines/gl_common/evas_gl_core_private.h
index 37e8cc5..254da65 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core_private.h
+++ b/src/modules/evas/engines/gl_common/evas_gl_core_private.h
@@ -212,7 +212,6 @@ struct _EVGL_Resource
struct {
 EVGLNative_Surface   surface;
 int  rendered;
-//Evas_Object *img;
 
 int  rot;
 int  win_w;

-- 

Re: [E-devel] [e-users] EFL developers days

[Sung W. Park]

wine tasting activity sounds nice.. ;-)

On Thu, May 12, 2016 at 1:50 AM, Tom Hacohen  wrote:

> It's dark inside anyway, so you wouldn't know any better. It's not
> necessarily an evening thing.
>
> The problem is that climbing is something that you need to be strong for,
> or at least have the technique, and many people don't like it (I personally
> do). The other one, the museum, is not a very good social event because you
> need to be quiet and you wander off on your own.
>
> I know it's not your thing, but another idea that just came to mind that is
> more of a Parisian themed idea: wine tasting activity, or a cooking
> activity or something of that sort.
>
> My personal favourite is bowling, but I think almost any idea is better
> than the museum (which because of the above we'll end up doing).
>
>
> On Wed, May 11, 2016 at 5:43 PM, Cedric BAIL  wrote:
>
> > On Wed, May 11, 2016 at 2:46 AM, Tom Hacohen 
> wrote:
> > > On 11/05/16 10:45, Tom Hacohen wrote:
> > >> On 11/05/16 08:50, Stefan Schmidt wrote:
> > >>> On 05/05/16 01:55, Cedric BAIL wrote:
> >  I would like to remind everyone that EFL developers days will happen
> >  later this month in Paris. If you have made your decision, it would
> be
> >  good to update your vote
> >  (
> >
> https://phab.enlightenment.org/w/events/enlightenment_developer_days_2016/
> > ).
> > 
> >  Also as a big part of the event is to do hacking together, don't
> >  hesitate to bring your prefered device along !
> > 
> >  Also as Saturday afternoon, we will try to setup some social event
> and
> >  by just the actual number of expected people, it will be necessary
> to
> >  book whatever we finally plan to do. So here is a vote
> >  https://phab.enlightenment.org/V23 . If people have other idea than
> >  climbing or visiting the Musee des Arts et Metiers, please raise
> your
> >  hands now ! The vote will be closed in a week from now.
> > >>>
> > >>> So far we only have 5 votes but 22 registered attendees. :)
> > >>>
> > >>> As an additional note please let me know if you have any input for
> > >>> hacking sessions we have planned.
> > >>> I will put some slides together with topics people can work on during
> > >>> this sessions.
> > >>
> > >> Posting again with some more info + both ML this time. :)
> > >>
> > >> I'm sorry I'm only bringing it up now, but I didn't see the vote. The
> > >> subject "EFL developers day" with the generic reminder first paragraph
> > >> meant I didn't read the rest of the email and see this. Please when
> you
> > >> have a "call for action" mark the title as such, or at the very least,
> > >> have a non generic title. I'm only seeing this now because of Stefan's
> > >> email.
> > >>
> > >> In the last email we talked about ideas there were plenty more, like
> > >> paintball and kart racing. Why are they not in this vote?
> > >
> > > Or bowling.
> >
> > There isnt any painball or kart racing track that I know of inside
> > Paris or at a short distance. Bowling is another possibility, but
> > isn't it more something you do in the evening ?
> > --
> > Cedric BAIL
> >
> >
> >
> --
> > Mobile security can be enabling, not merely restricting. Employees who
> > bring their own devices (BYOD) to work are irked by the imposition of MDM
> > restrictions. Mobile Device Manager Plus allows you to control only the
> > apps on BYO-devices by containerizing them, leaving personal data
> > untouched!
> > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
enlightenment-devel mailing list
enlightenment-devel@lists.so

[EGIT] [core/efl] master 01/01: evas gl: added partial rendering support for qcom extension

[Sung W . Park]

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=2b4a7b438def96d01a5c0bb85d2c9636773d333d

commit 2b4a7b438def96d01a5c0bb85d2c9636773d333d
Author: Sung W. Park 
Date:   Sat Feb 15 02:33:47 2014 +0900

evas gl: added partial rendering support for qcom extension

When running in direct rendering mode, properly support partial
rendering if the extension is properly supported.

Also, fixed the SwapBufferwWithDamage rectangle coordinate bug.
It wasn't properly y-inverted before.
---
 src/modules/evas/engines/gl_common/evas_gl_api.c   |  28 -
 .../evas/engines/gl_common/evas_gl_common.h|   9 +-
 .../evas/engines/gl_common/evas_gl_context.c   |  58 +++--
 src/modules/evas/engines/gl_common/evas_gl_core.c  | 132 +++--
 src/modules/evas/engines/gl_common/evas_gl_core.h  |  13 +-
 .../evas/engines/gl_common/evas_gl_core_private.h  |  10 +-
 src/modules/evas/engines/gl_x11/evas_engine.c  |  86 ++
 src/modules/evas/engines/wayland_egl/evas_engine.c |  14 ++-
 8 files changed, 298 insertions(+), 52 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_api.c 
b/src/modules/evas/engines/gl_common/evas_gl_api.c
index d831f9d..0555b4a 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_api.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_api.c
@@ -56,7 +56,9 @@ void
 _evgl_glBindFramebuffer(GLenum target, GLuint framebuffer)
 {
EVGL_Context *ctx = NULL;
+   EVGL_Resource *rsc;
 
+   rsc = _evgl_tls_resource_get();
ctx = _evgl_current_context_get();
 
if (!ctx)
@@ -69,13 +71,35 @@ _evgl_glBindFramebuffer(GLenum target, GLuint framebuffer)
if (framebuffer==0)
  {
 if (_evgl_direct_enabled())
-   glBindFramebuffer(target, 0);
+  {
+ glBindFramebuffer(target, 0);
+
+ if (rsc->direct.partial.enabled)
+   {
+  if (!ctx->partial_render)
+{
+   evgl_direct_partial_render_start();
+   ctx->partial_render = 1;
+}
+   }
+  }
 else
-   glBindFramebuffer(target, ctx->surface_fbo);
+  {
+ glBindFramebuffer(target, ctx->surface_fbo);
+  }
 ctx->current_fbo = 0;
  }
else
  {
+if (_evgl_direct_enabled())
+  {
+ if (ctx->current_fbo == 0)
+   {
+  if (rsc->direct.partial.enabled)
+ evgl_direct_partial_render_end();
+   }
+  }
+
 glBindFramebuffer(target, framebuffer);
 
 // Save this for restore when doing make current
diff --git a/src/modules/evas/engines/gl_common/evas_gl_common.h 
b/src/modules/evas/engines/gl_common/evas_gl_common.h
index 9e1579a..a6b624d 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_common.h
+++ b/src/modules/evas/engines/gl_common/evas_gl_common.h
@@ -531,6 +531,8 @@ struct _Evas_Engine_GL_Context
void *egldisp;
void *eglctxt;
 #endif
+
+   GLuint preserve_bit;
 };
 
 struct _Evas_GL_Texture_Pool
@@ -692,7 +694,12 @@ void  
evas_gl_common_context_free(Evas_Engine_GL_Context *gc);
 void  evas_gl_common_context_use(Evas_Engine_GL_Context *gc);
 void  evas_gl_common_context_newframe(Evas_Engine_GL_Context *gc);
 void  evas_gl_common_context_resize(Evas_Engine_GL_Context *gc, 
int w, int h, int rot);
+void  evas_gl_common_tiling_start(Evas_Engine_GL_Context *gc,
+  int rot, int gw, int gh,
+  int cx, int cy, int cw, int ch,
+  int bitmask);
 void  evas_gl_common_context_done(Evas_Engine_GL_Context *gc);
+void  evas_gl_common_tiling_done(Evas_Engine_GL_Context *gc);
 void  
evas_gl_common_context_target_surface_set(Evas_Engine_GL_Context *gc, 
Evas_GL_Image *surface);
 
 void  evas_gl_common_context_line_push(Evas_Engine_GL_Context *gc,
@@ -818,7 +825,7 @@ void  
evas_gl_common_poly_draw(Evas_Engine_GL_Context *gc, Evas_GL_P
 
 void  evas_gl_common_line_draw(Evas_Engine_GL_Context *gc, int x1, 
int y1, int x2, int y2);
 
-int   evas_gl_common_buffer_dump(Evas_Engine_GL_Context *gc, const 
char* dname, const char* fname, int frame);
+int   evas_gl_common_buffer_dump(Evas_Engine_GL_Context *gc, const 
char* dname, const char* fname, int frame, const char* suffix);
 
 extern void   (*glsym_glGenFramebuffers)  (GLsizei a, GLuint *b);
 extern void   (*glsym_glBindFramebuffer)  (GLenum a, GLuint b);
diff --git a/src/modules/evas/engines/gl_common/evas_gl_context.c 
b/src/modules/evas/engines/gl_common/evas_gl_context.c
index 5626ce4..2e447d9 100644
--- a/src/m

[EGIT] [core/elementary] master 01/01: elementary_test glview: fixed segv on close

[Sung W . Park]

sung pushed a commit to branch master.

http://git.enlightenment.org/core/elementary.git/commit/?id=5c65df8c7f4ddae5f916fa48e6063c7f2133cb58

commit 5c65df8c7f4ddae5f916fa48e6063c7f2133cb58
Author: Sung W. Park 
Date:   Sat Feb 22 03:15:57 2014 +0900

elementary_test glview: fixed segv on close

It was deleting gldata object twice upon closing the program.
---
 src/bin/test_glview.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/bin/test_glview.c b/src/bin/test_glview.c
index 463761c..c840b97 100644
--- a/src/bin/test_glview.c
+++ b/src/bin/test_glview.c
@@ -516,9 +516,7 @@ static void
 _del(void *data EINA_UNUSED, Evas *evas EINA_UNUSED, Evas_Object *obj, void 
*event_info EINA_UNUSED)
 {
Ecore_Animator *ani = evas_object_data_get(obj, "ani");
-   GLData *gld = evas_object_data_get(obj, "gld");
ecore_animator_del(ani);
-   free(gld);
 }
 
 static void

-- 

[EGIT] [core/efl] master 01/01: evas_gl : Fixed macro substitution bug in evas_gl

[Sung W . Park]

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=90bbc21d02b9cdc7e074884812950d27e015c2ac

commit 90bbc21d02b9cdc7e074884812950d27e015c2ac
Author: Sung W. Park 
Date:   Wed Nov 13 15:39:12 2013 +0900

evas_gl : Fixed macro substitution bug in evas_gl

In evas_gl_api_ext_def.h there're calls such as:

_EVASGL_EXT_DRVNAME(EGL_KHR_image_base)

The macro is defined in evas_gl_api_ext.c as:

(strstr(glexts, #name) != NULL || strstr(glueexts, #name) != NULL)

if (_EVASGL_EXT_CHECK_SUPPORT(name)) *ext_support = 1;

But EGL_KHR_image_base is itself a macro, which is defined
in EGL/eglext.h like this:

Thus, the _EVASGL_EXT_CHECK_SUPPORT macro will unwrap into:

(strstr(glexts, "1") != NULL || strstr(glueexts, "1") != NULL)

instead of intended:

(strstr(glexts, "EGL_KHR_image_base") != NULL ||
 strstr(glueexts, "EGL_KHR_image_base") != NULL)

This patch fixes this by applying stringification earlier in
_EVASGL_EXT_DRVNAME

Bugfix reported by jinhyung...@samsung.com
---
 src/modules/evas/engines/gl_common/evas_gl_api_ext.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_api_ext.c 
b/src/modules/evas/engines/gl_common/evas_gl_api_ext.c
index dcf5f1c..0573c6d 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_api_ext.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_api_ext.c
@@ -184,13 +184,13 @@ re->info->info.screen);
  }
 
 #define _EVASGL_EXT_CHECK_SUPPORT(name) \
-   (strstr(glexts, #name) != NULL || strstr(glueexts, #name) != NULL)
+   (strstr(glexts, name) != NULL || strstr(glueexts, name) != NULL)
 
 #define _EVASGL_EXT_DISCARD_SUPPORT() \
*ext_support = 0;
 
 #define _EVASGL_EXT_DRVNAME(name) \
-   if (_EVASGL_EXT_CHECK_SUPPORT(name)) *ext_support = 1;
+   if (_EVASGL_EXT_CHECK_SUPPORT(#name)) *ext_support = 1;
 
 #define _EVASGL_EXT_FUNCTION_BEGIN(ret, name, param) \
  { \

-- 

Re: [E-devel] evas_3d_utils.h should be public.

[Sung W. Park]

From what I recall, the reason why the util functions was to keep the
evas_3d a high level library.  and so we put a lot of time into designing
the apis.   that's the reason why it was hidden initially. if you guys
think it's good to expose the math functions, i guess it'd be fine.

-Sung


On Tue, May 27, 2014 at 11:21 AM, ChunEon Park  wrote:

> There would be bunch of 2d/3d math types/functions(for matrixs, vectors,
> planes, quarternions...)  required once evas afford 3d stuffs.
> This kind of functions will be very commonly useful for 2d/3d graphics
> computation in efl/app.
>
> 
> -Regards, Hermet-
>
> -Original Message-
> From: "Cedric BAIL"
> To: "Enlightenment developer list"<
> enlightenment-devel@lists.sourceforge.net>;
> Cc:
> Sent: 2014-05-26 (월) 22:31:27
> Subject: Re: [E-devel] evas_3d_utils.h should be public.
>
> On Mon, May 26, 2014 at 7:13 AM, David Seikel @gmail.com> wrote:
> > On Mon, 26 May 2014 13:44:49 +0900 (KST) ChunEon Park
> > @naver.com> wrote:
> >> Agree your opinion.
> >> and let them in Eina Math?
> >
> > I don't see anything called Eina math, but that sounds like a logical
> > place, even if we have to create it.
>
> Would make sense to me to.
> --
> Cedric BAIL
>
>
> --
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/elementary] master 01/01: ELM_GLView: added glview_manygears example to elementary_test

[Sung W . Park]

sung pushed a commit to branch master.

http://git.enlightenment.org/core/elementary.git/commit/?id=8e2d312aeb28e8cf64f47eafda425e3566cef290

commit 8e2d312aeb28e8cf64f47eafda425e3566cef290
Author: Sung W. Park 
Date:   Wed Mar 26 00:26:46 2014 +0900

ELM_GLView: added glview_manygears example to elementary_test

Added a more complex glview example to the elementary test.

- the gears lighting matches the original glx gears example.
- Added a background image to show that Glview works well with existing
  ELM winsets.
- Added 5 gears and buttons to increase/decrease gear teeth
---
 src/bin/Makefile.am |   1 +
 src/bin/test.c  |   6 +-
 src/bin/test_glview_manygears.c | 951 
 3 files changed, 956 insertions(+), 2 deletions(-)

diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am
index 3ebd91f..98b20fc 100644
--- a/src/bin/Makefile.am
+++ b/src/bin/Makefile.am
@@ -82,6 +82,7 @@ test_gesture_layer2.c \
 test_gesture_layer3.c \
 test_glview_simple.c \
 test_glview.c \
+test_glview_manygears.c \
 test_grid.c \
 test_hover.c \
 test_hoversel.c \
diff --git a/src/bin/test.c b/src/bin/test.c
index 1dd840c..268f739 100644
--- a/src/bin/test.c
+++ b/src/bin/test.c
@@ -211,6 +211,7 @@ void test_win_wm_rotation(void *data, Evas_Object *obj, 
void *event_info);
 void test_grid(void *data, Evas_Object *obj, void *event_info);
 void test_glview_simple(void *data, Evas_Object *obj, void *event_info);
 void test_glview(void *data, Evas_Object *obj, void *event_info);
+void test_glview_manygears(void *data, Evas_Object *obj, void *event_info);
 void test_3d(void *data, Evas_Object *obj, void *event_info);
 void test_naviframe(void *data, Evas_Object *obj, void *event_info);
 void test_naviframe2(void *data, Evas_Object *obj, void *event_info);
@@ -671,9 +672,10 @@ add_tests:
ADD_TEST(NULL, "General", "Scaling 2", test_scaling2);
 
//--//
-   ADD_TEST(NULL, "3D", "GLViewSimple", test_glview_simple);
-   ADD_TEST(NULL, "3D", "GLView", test_glview);
ADD_TEST(NULL, "3D", "Evas Map 3D", test_3d);
+   ADD_TEST(NULL, "3D", "GLViewSimple", test_glview_simple);
+   ADD_TEST(NULL, "3D", "GLView Gears", test_glview);
+   ADD_TEST(NULL, "3D", "GLView Many Gears", test_glview_manygears);
 
//--//
 #ifdef HAVE_ELEMENTARY_WEB
diff --git a/src/bin/test_glview_manygears.c b/src/bin/test_glview_manygears.c
new file mode 100644
index 000..34627a5
--- /dev/null
+++ b/src/bin/test_glview_manygears.c
@@ -0,0 +1,951 @@
+/*
+ * Copyright (C) 1999-2001  Brian Paul   All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+ * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Ported to GLES2.
+ * Kristian Høgsberg 
+ * May 3, 2010
+ *
+ * Improve GLES2 port:
+ *   * Refactor gear drawing.
+ *   * Use correct normals for surfaces.
+ *   * Improve shader.
+ *   * Use perspective projection transformation.
+ *   * Add FPS count.
+ *   * Add comments.
+ * Alexandros Frantzis 
+ * Jul 13, 2010
+ *
+ * Ported to Elm_GLView and added features for testing purposes:
+ ** Has 5 gears
+ ** Number of teeth can be increased to test under many vertices
+ ** Up/Down button increases the teeth number
+ * Sung W. Park 
+ * (Some positioning and numbers taken from KHCho's example)
+ * Oct 27, 2011
+ *
+ */
+#ifdef HAVE_CONFIG_H
+# include "elementary_config.h"
+#endif
+#include 
+
+#ifndef M_PI
+#define M_PI 3.14159265
+#endif
+
+#define STRIPS_PER_TOOTH 7
+#define VERTICES_PER_TOOTH 34
+#define GEAR_VERTEX_STRIDE 6
+
+/* A set of macros for making the creation of the gears easier */
+#define  GEAR_POINT(r, da) { (r) * c[(da)], (r) * s[(da)] }
+#define  SET_NORMAL(x, y, z) do { \
+ normal[0] = (x); normal[1] = (y); norm

Re: [E-devel] wayland.. egl.. barf!

[Sung W. Park]

are you sure Cedric was a sounding board? or was he the one who created the
bug in the first place and then pretended like he gave you excellent
feedback? =P


On Tue, Aug 19, 2014 at 5:19 AM, Chris Michael 
wrote:

> On 08/18/2014 04:16 PM, Chris Michael wrote:
> > On 08/18/2014 02:01 AM, Carsten Haitzler (The Rasterman) wrote:
> >> elm engine is wayland_egl:
> >>
> >> http://www.enlightenment.org/ss/e-53f19667607690.40512419.png
> >>
> >> need i say more.
> >>
> >> WAT?
> >>
> >
> > Fixed now ! :)
> >
> > Thanks Cedric for being a sounding board !! ;)
> >
> > Cheers,
> > dh
>
> Well, sort of fixed. It's no longer a black rectangle :D ... but there
> are some issues when manually resizing. I'll poke some more tomorrow on it.
>
> Cheers,
> dh
>
>
>
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Problem running evas_3d_cube example

[Sung W. Park]

I could be wrong but it seems like your gles compiler's complaining about
precision not being set in the shader.

Some GLES compilers will complain and others gracefully ignores it if one's
not found.

I don't have time to look at the code as I'll be away for the weekend but
you may look at the evas_3d  fragment shader code and see if there's
something like

  "precision mediump float;\n"  or
  "precision highp float;\n"

is in there somewhere

that would be my guess.

good luck.
Sung


On Fri, Nov 7, 2014 at 6:55 PM, Brian Wang 
wrote:

> On Fri, Nov 7, 2014 at 5:49 PM, ChunEon Park  wrote:
>
> > failed compile shader sources with your opengl driver.
> >
> > did u launch the elementary_test with gl ?
> >
> > $ELM_ENGINE=gl elementary_test
> >
>
> Yes, elementary_test is run with ELM_ENGINE=gl.  The gears spin smoothly
> without problems.
> It is the evas_3d_cube and other evas 3D examples that are causing the
> problem.
>
> Is it a setup problem?
>
> Thank you.
>
>
> Brian
>
>
> >
> > 
> > -Regards, Hermet-
> > -Original Message-
> > From: "Brian Wang"
> > To: "e";
> > Cc:
> > Sent: 2014-11-07 (금) 17:36:37
> > Subject: [E-devel] Problem running evas_3d_cube example
> >
> > Hello all,
> >
> > I tried to run evas_3d_cube example on my board.  Lots of error messages
> > output like these:
> > ---
> > ERR<498>:evas_main
> modules/evas/engines/gl_common/evas_gl_3d_shader.c:1112
> > _shader_compile() Shader compilation failed.
> > 0:1: S0032: no default precision defined for variable
> > ERR<498>:evas_main
> modules/evas/engines/gl_common/evas_gl_3d_shader.c:1140
> > _program_build() Failed to compile fragment shader.
> > ERR<498>:evas-gl_common
> > modules/evas/engines/gl_common/evas_gl_3d_renderer.c:229
> > e3d_renderer_draw() Failed to create shader program.
> > ---
> >
> > EFL version is 1.11.  I had the gears test of elementary_test running ok.
> > I have no clue if this is my environment setup or a problem with EFL.
> >
> > Any hints will be appreciated.
> >
> > Thanks in advance.
> >
> >
> > Brian
> >
> >
> > --
> > brian
> > --
> >
> > iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe
> >
> >
> --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
>
> --
> brian
> --
>
> iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Possible OpenGL ES 2.0 + Evas 3D Incompatibility Problem - only EVAS_3D_SHADE_MODE_DIFFUSE works

[Sung W. Park]

Hi Brian,

Unfortunately, Evas 3D hasn't been extensively tested on a lot of GPUs,
especially on the one that you're using.  From what I know about Mali
400mp, it's an older GPU with separate vertext/fragment processors.  By the
way, I'm not the one who developed the library so I don't know all the
details.  From what I know about GPUs and from what I recall, it was only
tested on a qualcomm mobile chipset.  The developement happened on a
desktop machine.

Looking at your description, it appears that Mali 400mp has a hard time
processing the shader code for other types of lighting mode, which would
inevitabily require more complex shader codes.  I guess one thing that you
need to find out is if Mali400mp supports the kind of shader code that's
there.  like the number of uniforms and the complexity of the code.  If it
doesn't support the code, then i guess you'd need to figure out if you can
do a workaround.  Unfortunately, both of these require good understanding
of shaders.

I'm CC'ing Taekyun, the guy who wrote most of it, so he can aslo respond.

Sorry for the late response.  I got completely swamped with work after the
weekend.

Hope you can get it sorted out.

cheers,
Sung




On Thu, Nov 13, 2014 at 12:29 PM, Brian Wang 
wrote:

> Hello all,
>
> Symptoms:
> Running efl/src/examples/evas/evas-3d-xxx.c examples in efl-1.11 is
> generally unsuccessful on my target box (Allwinner A13 with Mali-400 MP
> GPU).  They often result in no rendering at all.
> Everything runs fine on my x86 box though (not OPENGL ES 2.0, I suppose)
>
> After some experiments, I have found that only EVAS_3D_SHADE_MODE_DIFFUSE
> works.  Other shade modes, like vertex color, phong, map, etc., simply
> result in no rendering at all.
>
> I have been littering glGetError/GLERR calls in evas_3d files but could not
> get any further.  There are no warnings or errors while running the
> non-rendering examples.  Changing the shade mode to DIFFUSE will make the
> objects, say cube, appear on the screen.
>
> I did find some discrepancies between EFL and OPENGL ES document though.
> 1.  Default precision should be set in the shader code.  Some GPU
> implementations are pretty strict...
> 2.  glTexImage2D usage may not be proper.  In
> evas_gl_3d.c:e3d_texture_data_set(), glTexImage2D is called with different
> internal format and format, while the the official doc states that the
> internal format must match format.  (Ref:
> https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml).
>
> What can I do to narrow down the problem?  _shader_compile does not issue
> any message.
>
> Any help is much appreciated.
>
> Thanks in advance.
>
>
> Brian
>
> --
> brian
> --
>
> iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe
>
> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: EvasGL: Fixed a bug where the wrong data variable to buffer alloc func.

[Sung W . Park - Enlightenment Git]

sung pushed a commit to branch master.

commit b9e3e6be57e178ce83433447bbaf79fbbda0f653
Author: Sung W. Park 
Date:   Tue Sep 17 17:22:26 2013 +0900

EvasGL: Fixed a bug where the wrong data variable to buffer alloc func.

It's an optional feature so it's not automatically turned on but
would have caused a segfault somewhere.  Somehow slipped notice
but fixed now.
---
 src/modules/evas/engines/gl_common/evas_gl_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.c 
b/src/modules/evas/engines/gl_common/evas_gl_core.c
index 5ae7a9e..c711a26 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.c
@@ -1695,7 +1695,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc, 
EVGL_Context *ctx)
  // Destroy created resources
  if (sfc->buffers_allocated)
{
-  if (!_surface_buffers_allocate(evgl_engine, sfc, 0, 0, 1))
+  if (!_surface_buffers_allocate(eng_data, sfc, 0, 0, 1))
 {
ERR("Unable to destroy surface buffers!");
return 0;
@@ -1708,7 +1708,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc, 
EVGL_Context *ctx)
  // Create internal buffers if not yet created
  if (!sfc->buffers_allocated)
{
-  if (!_surface_buffers_allocate(evgl_engine, sfc, sfc->w, 
sfc->h, 1))
+  if (!_surface_buffers_allocate(eng_data, sfc, sfc->w, 
sfc->h, 1))
 {
ERR("Unable Create Specificed Surfaces.  Unsupported 
format!");
return 0;

--