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