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 <ras...@rasterman.com>wrote: > 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
