i'm glad we got to this point =) On Fri, Mar 25, 2011 at 2:59 PM, Carsten Haitzler <ras...@rasterman.com>wrote:
> On Wed, 16 Mar 2011 16:26:44 +0900 "Sung W. Park" <sung...@gmail.com> > 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 <GLES2/gl2.h> > #include <GL/gl.h> > > 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. 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
