[E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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)
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 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). > 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. > 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. Hehe, looks nice :-) Examples are easy to understand and make this API sounds good. > I just tested with a fresh co from SVN and have applied the patches. I hope > it works. I confirm it run well on my computer :-) > thanks in advance for your comments! That's good ! Could have been my only comment ;-) -- Cedric BAIL -- 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)
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 default. > > Hehe, looks nice :-) Examples are easy to understand and make this API > sounds good. > > > I just tested with a fresh co from SVN and have applied the patches. I > hope > > it works. > > I confirm it run well on my computer :-) > > > thanks in advance for your comments! > > That's good ! Could have been my only comment ;-) > -- > Cedric BAIL > Let me know if you guys have other comments/suggestions. cheers, Sung -- Colocation vs. Managed Hosting A question and answer
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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. >> 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 would be cleaner imho, but as you say not that much necessary. Not a blocker in my opinion. >> > 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 default. >> >> Hehe, looks nice :-) Examples are easy to understand and make this API >> sounds good. >> >> > I just tested with a
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
Good ! I added you to evas.dox.in as well. You'll see your name on below page later. (It takes time changes to be applied to the web page.) http://docs.enlightenment.org/auto/evas/ Thanks. Daniel Juyung Seo (SeoZ) 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. > >>> 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 would be cleaner imho, but as you say not > that much necessary. Not a blocker in my opinion. > >>> > 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. evasglsample
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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 would be cleaner imho, but as you say not > that much necessary. Not a blocker in my opinion. > It would be cleaner. Maybe I'll revisit it at a later time. I'm taking tomorrow off to get some rest finally =) > > >> > 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. exa
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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 >> >> 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 would be cleaner imho, but as you say not >> that much necessary. Not a blocker in my opinion. >> > > It would be cleaner. Maybe I'll revisit it at a later time. I'm taking > tomorrow > off to get some rest finally =) > > >> >> >> > 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 v
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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 > >> >> 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 suggestio
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
Hello I was talking about evas_gl.c Is that a fresh new file? Sorry I missed it. So never mind. Thanks. Daniel Juyung Seo (SeoZ) On Mar 24, 2011 1:34 PM, "Sung W. Park" wrote: > 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 >> >> >> 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 d
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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 :) 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". 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). 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). > 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 -- - 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)
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 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. exa
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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 make your life easier" eg like providing some standard shaders, some other things etc. that are IN ADDITION to gles2 calls, then they can port anything they already have working on gles2 and then make their code simpler if using evas. no need to do from day 1. just something to keep in mind imho :) > > 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 =) i've had to deal with this once before and was faced with readback recently. > can you elaborate on the shader readback? give glsl to opengl, then ask gl for the compiled shader binary back so NEXT time u deal with the same gpu and shame shader.. u can just upload the compiled binary from before: ogl3: http://developer.download.nvidia.com/opengl/specs/GL_ARB_get_program_binary.txt side-note. i was wrong. this is ogl3 not a gles2 subset.. so maybe we can't sanely do this. so its glsl runtime compiling only. :( boo. that kills off a whole plan/idea... major poops. :( > 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. yes. make changes, send updated patches - work progressively towards the goal :) > 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
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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 make your > life > easier" eg like providing some standard shaders, some other things etc. > that > are IN ADDITION to gles2 calls, then they can port anything they already > have > working on gles2 and then make their code simpler if using evas. no need to > do > from day 1. just something to keep in mind imho :) > yeah.. once i get started on this part, I'll factor in these things and then start a discussion. > > > > 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
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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. :) > 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 make your > > life > > easier" eg like providing some standard shaders, some other things etc. > > that > > are IN ADDITION to gles2 calls, then they can port anythi
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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)
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
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
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
Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)
On Mon, 11 Apr 2011 21:04:38 +0900 "Sung W. Park" said: > 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? no. it souldn't. it actually can't. textures data is opaque (normally). data get here will return null once you use a native surface. > 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? ok. important thung here. think x windows + bg pixmap. what happens when u resize a window in x when it has a bg pixmap set? it tiles :) in evas. you can SEt this tiling offset AND size explicitly with fill_set(). you can also tell evas to have the image filled (always scale the image to fill the size of the obj) but this is all done at render time. the ORIGINAL image (texture) size remains. resizing image has no effect on the original data. it just changes the output "region". fill/dilled define how that output region is... filled :) > 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. you may define semantic any way you like in a higher level obj - eg always stretch (like gl does), or... in your higher level obj always modify the texture/imaghe buffer to be 1:1 to the image object size (beware.. what if image object is 1,000,000 x 1,000,000 in size? :)). > 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? > > > > > > Th
