On Tue, 5 Apr 2011 10:53:45 +0900 "Sung W. Park" <sung...@gmail.com> 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
