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
>
>
evas_gl_updated.tgz
Description: GNU Zip compressed data
------------------------------------------------------------------------------ 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
