add a package check for gl_eet or else the gl_common code will not
build.
Signed-off-by: Christopher Michael <devilhorns@revolution.(none)>
SVN revision: 78573
Only one of them is necessary, based on the gl_flavor_gles flag. Also
remove some extra checks and added link flags, since they are already
done by pkg-config.
SVN revision: 78555
NOTE: I would like to do the same with software SDL 16bits engine.
But as we don't have a buffer_16 backend, I am likely to just remove
it and use buffer conversion code to match a 16bits target. This
will come with a performance impact, that will make it useless. So
I am just tempted to completly remove it.
SVN revision: 68352
'gl_flavor_gles' when checking for sgx support (if we reset
gl_flavor_gles here, then the autofoo output always returns 'NO' for
gles.
SVN revision: 67572
old version of this w/ the 3 includes Should be working, but I've
tested it on 2 machines now, and it fails on both with those lines in
there, so I am removing them).
Make wayland_egl engine Actually work and draw stuff now (too many
code changes to list them all separately). See http://i.imgur.com/i2eBE.png.
SVN revision: 67128
Subject: [E-devel] [Patch] Evas gl shader use binary shader
I make patch related with evas gl binary shader.
The concept of binary shader is compile shader only once.
Some people want to use binary shader because of performance issue.
In current evas gl engine, every application have to compile shader each
time.
But I modify code , so only first running application need compile shader.
Other application use already compiled shader(binary shader)
The binary shader is made under HOME/.evas/gl_common_shaders directory.
Binary shader is created according to GL vendor,GL renderer, GL version and
Module_arch.
The basic flow is
1. First running application which use gl engine check binary shader
directory, but it can't find binary shader.
2. After compiling shader, It saves compiled shaders..
3. Other application checks shader directory, it can use binary
shaders.
In mobile target, using binary shader, I can save 150ms. (that time, there
is 11 shaders).
If there is more shaders and more applications, this flow maybe save more
total time.
(the above is now in, changelog coming, with change to using ~/.cache,
some formatting fixes, make ity do the desktop gl one right with the
retrievable hint parameter ont he program etc. - doesn't break desktop
gl at least. yay. a,so fixes to mke it compile at all).
SVN revision: 59167
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
Subject: [E-devel] 8bpp xcb evas engine
Hi all,
I've implemented the 8bpp grayscale evas engine. It is based on the 16bpp
engine. It would be nice if someone could review the code and maybe commit
into svn. The patches against evas and ecore are attached.
SVN revision: 50560
files detection. It should work with and without an
Objective C compiler. The problem is a bug in the
AC_PROG_OBJC macro.
Patch by Ralf Wildenhues
SVN revision: 46890
* allow the build of evas without xlib installed (for OpenInkpot guys)
* add big fat warning when at least a module is linked statically (try it !)
more patches will follow now (ecore, e, rage and ewl)
I let pyton and c++ bindings maintainer to do the rename
SVN revision: 41329
a way to select it with --enable-foo by passing
'static'. Use at your own risks.
If I've messed something up, please report in that thread
SVN revision: 41160
Christopher Michael
Rafael Antognolli
Carsten Haitzler
Vincent Torri
Cedric BAIL
Youness Alaoui
Nicolas Aguirre
Jiyoun Park
Sung W. Park
Michael Jennings
Alexander Kerner
xcomputerman
Raoul HECKY
