On Mon, 7 Mar 2011 17:33:00 +0900 "Sung W. Park" <sung...@gmail.com> said:
ok - i skipped all the way to this mail since this already was discussed and you've moved on 1 step. :) > Hi all, > > In my earlier post, I've discussed about the issues with getting the > > evas_object_image_native_surface_set(..., Evas_Native_Surface *surf); > > function for setting OpenGL output texture. There was also a disucssion > about how Evas should provide a GL glue layer. We've discussed two > proposals. > After some discussion, I went ahead with the preferred way and have > implemented the APIs. > > The APIs go something like... (in Evas_GL.h) > > EAPI Evas_GL *evas_gl_new (Evas *e); > EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL *evas_gl, > Evas_GL_Config *cfg, int w, int h); > EAPI Evas_GL_Context *evas_gl_context_create (Evas_GL *evas_gl, > Evas_GL_Context *share_ctx); > EAPI Eina_Bool evas_gl_make_current (Evas_GL > *evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx); > EAPI Evas_GL_Func evas_gl_proc_address_get (Evas_GL *evas_gl, > const char *name); > > EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL > *evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns); > > I actually have the above APIs running on my machine but > instead of dumping the entire thing, I wanted to get incremental comments > for review. thats actually really sensible :) most happy with the way you're handling this. do some local experiments - see if something works at all or not, see if you feel comfortable with it, then propose the idea/solution before you go too much further and flesh it out so as not to waste time. :) what you have there looks very sensible to me. its the "necessary" bits you'd find in EGL/glX etc. etc. needed to bind gl to evas.. BUT in a way that returns handles so evas can deal with it nicely :) one thing that an eventual implementation of this will need is both a "gl" and "software" path. the software path may literally us importing a special build of mesa with all the software rendering only enabled and glued to render to ARGB software buffers. how precisely this will happen/work in detail is a matter i guess for actual implementation, BUT it will be needed as we have to "not fail" if you switch engines to software. be slower, sure. fail (either crash, have missing symbols or just whole parts of the canvas go unrendered) is bad. we dont need to do this right away, BUT we do need to "design for this" and at the api level that looks all perfectly possible. > I'm now attaching Evas_GL.h and evas_gl.c and a Sample program that uses the > APIs. > > Your comments would be very much appreciated. After the initial review, > I'll submit > a RFC for the engine part of the code that I wrote for gl_x11 module. > > One issue that I ran into with the above APIs is that Evas_GL_Context is > already used > by the gl_common part of the code in the engine module. Upon discussing it > with Raster, > the consensus was that it was better to change the internal code since it's > not exposed. > So, in my implementation, I've changed the internal part to > Evas_Engine_GL_Context. > I just wanted to mention that here for now even though it won't show in the > files that i'm > attaching. yup. change the internal type name - no problems there. otherwise i'm relatively happy with the api as i see it there and the implementation code - of course accounting for the fact that the engine will provide a gl_surface_create and gl_context_create call. now one thing. evas_gl_proc_address_get() is all fine and good. do you expect apps to have to get proc address of EVERY gl api call? are we not going to provide a pre-fetched set of "standard gl calls" in a struct or something? oh and one other thing. on evas_gl_free() shouldnt we also track and free all the gl contexts, surfaces etc. that were created via the gl object? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
