On Mon, 11 Apr 2011 21:04:38 +0900 "Sung W. Park" <sung...@gmail.com> said:
> 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? no. it souldn't. it actually can't. textures data is opaque (normally). data get here will return null once you use a native surface. > 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? ok. important thung here. think x windows + bg pixmap. what happens when u resize a window in x when it has a bg pixmap set?.... it tiles :) in evas. you can SEt this tiling offset AND size explicitly with fill_set(). you can also tell evas to have the image filled (always scale the image to fill the size of the obj) but this is all done at render time. the ORIGINAL image (texture) size remains. resizing image has no effect on the original data. it just changes the output "region". fill/dilled define how that output region is... filled :) > 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. you may define semantic any way you like in a higher level obj - eg always stretch (like gl does), or... in your higher level obj always modify the texture/imaghe buffer to be 1:1 to the image object size (beware.. what if image object is 1,000,000 x 1,000,000 in size? :)). > 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 > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
