On Thu, 31 Mar 2011 23:02:09 +0900 "Sung W. Park" <sung...@gmail.com> said:
i've had to fix a few things - but it's in svn now. it's not complete - for sure. btw. hint: export CFLAGS="-W -Wall -Wextra" :) beware the warnings! also .. for gl proc address getting.. i actually get the address.. of getprocaddress... i know. it's like checking you have your pants on after you've already walked out the front door... but i've encountered gl libs which dont have it... thus the dlsym fallback. :) > Ok, i'm attaching the latest patch with the fixes discussed from the thread. > > I'm attaching the following files. > > 1. evas_gl.patch > - This patch includes the image_object_native_surface_set() patch > (I've added the code for hashing the image object.) > - And, it has the rest of the code that allows evas_gl to run for gl_x11 > engine. > > 2. Evas_GL.h > - This files goes in > src/lib/ > > 3. evas_gl.c > - I've added the Evas magic check in evas_gl_new() > - This files goes in > src/lib/canvas/ > > 4. examples/ > - as discussed in the previous thread. I've used the animator callback in > evasglgears. > - i have tried using the image_pixel_get_callback_set as Carsten discussed > but I wasn't > getting any images out on Linux so I've commented it out for now. > > Hopefully I've covered all the basis for this patch. > More to come in the near future hopefully. > > > On Tue, Mar 29, 2011 at 6:05 PM, Carsten Haitzler <ras...@rasterman.com>wrote: > > > 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 :) > > > > yeah.. once i get started on this part, I'll factor in these things and then > start a > discussion. > > > > > > > > 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 :) > > > > > attaching one =) > > cheers, > Sung > > > > > 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 > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
