On Fri, 25 Mar 2011 17:28:48 +0900 "Sung W. Park" <sung...@gmail.com> said:
> > 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. =) 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 <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 =) 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 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 > > > > -- ------------- 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
