This patch refactors common code for image draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79795
This patch refactors common code for rectangle draws - so that it can be
used by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79785
Hi all,
I had prepare some fix for evas_object_key_grab function.
In my opinion when given modifiers are equal it should return FALSE.
Please verify attached file.
Regards,
Patrick
Signed-Off-By: Patryk Kaczmarek<patryk.k@samsung.com>
SVN revision: 79563
direct rendering and then another image object using Native
Surface rendering, there was a potential for it to fall into
the same direct rendering path.
Also, fixed some minor Evas GL extension bugs that came from refactoring.
SVN revision: 79532
EGL 1.4 spec Section 3.5.1: If there is already an
EGLSurface associated with win (as a result of a previous
eglCreateWindowSurface call), then an EGL_BAD_ALLOC error is
generated.
So that this eglCreateWindowSurface() will fail if the egl driver is
a strict conformance to the spec.
SVN revision: 79505
weren't set properly where if a program uses evas_gl to do GL rendering
in direct rendering mode and then use a pixmap to do native
GL rendering in the same program, native pixmap rendering would
also fall into the direct rendering path and not render anything for
image object. It's been fixed.
SVN revision: 79493
saddly eina_bench stills segv and as I can't find any install target for
it, and I'm not a kung-auto-foo warrior, I can't gdb it.
could someone provide a benchmark-install target or point me to the
direction I missed?
Patch by: Jérémy Zurcher <jeremy@asynk.ch>
SVN revision: 79448
x1, x2 shadow something in the math library.
Would probably be better to turn off -Wshadow, but for some
reason people think this there's some value in it...
Signed-off-by: Mike McCormack <mikem@atratus.org>
SVN revision: 79446
Unfortunately setting unused variable to zero still produces
a warning about variables being set but not used (on gcc 4.6.3).
Signed-off-by: Mike McCormack <mikem@atratus.org>
SVN revision: 79445
This was removed on latest mesa, and seems to don't belong to GLES. See
the specification at http://www.khronos.org/registry/gles/.
Additionally, it wasn't being used anywhere.
SVN revision: 79400
This caused automake to generate a faulty Makefile, which in turn caused
compilation to fail.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 79345
config wasa being chosen as it was done by hand not accounting for
multisample buffers. now using glxchoosefbconfig instead and it works.
SVN revision: 79232
and use the Point structure for clean code.
Signed-Off-By: Leandro Dorileo<dorileo@profusion.mobi>
Signed-Off-By: ChunEon Park<hermet@hermet.pe.kr>
SVN revision: 79224
It doesn't affect proto/eobj so no need to do it there too.
There are things we only test if NDEBUG is not passed to Eo. Eo itself was
compiled with NDEBUG but the tests were not notified about it so those tests
failed.
Many thanks to Vincent and Stefan for bugging me about it non-stop, without
you guys, I may never have gotten to it.
SVN revision: 79059
This pointer could be NULL if the window was hidden before calling
glMakeCurrent, which would make the program crash. In fact, at least
elm_win hides the window before actually deleting it (thus calling this
function).
SVN revision: 79017
We need to pass -sse3 to compile only in the file that checks for SSE3.
Otherwise even for plain C compiler is free to use sse3 instructions. But they
won't work if the CPU doesn't support it and therefore will SIGILL.
SVN revision: 78973
* remove magic debug output in evas part
* always use version for pc file, it's actually safe
* fix compilation of gl-sdl
* avoid circular dependency of libevas on itself
SVN revision: 78935
* gl engines were checking for eet module, which does not
exist when we install first the efl package.
* fix pkgconfig values for static linking
* add Evas output to configure
SVN revision: 78918
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
When creating the rules to build, we can't declare the lib dependencies in
LDADD/LIBADD using $(top_builddir)/libbla.la because automake doesn't know this
is related to the libbla_la rule.
Please check if evil works, too. Since I don't run evil code, it's untested.
SVN revision: 78800
Please check.
note1: Only lib and bin for now, but should be extended to other stuff
note2: distcheck does not work because eo_suite is failing.
SVN revision: 78758
It's not working yet:
* eina_thread.c:152:33: error: 'index' undeclared (first use in this function)
* eina_thread.c:295:4: warning: passing argument 3 of '_eina_thread_win32_create' from incompatible pointer type [enabled by default]
also:
* line 142, is it normal that we call eina_list_append() with tw being NULL ?
* is what I did in the close_thread label correct ?
SVN revision: 78416
eina headers used to be in their own directory, but now they live
inside src/lib/eina. The mempools were still including
include/lib/eina/ and with "sed" they became src/lib/eina/, which
already existed.
SVN revision: 77837
it's still not merged into EFL single tree, but once it is we should
use "HAVE_EXOTIC" define to work with it.
Before we had: EINA_HAVE_EXOTIC (not used), HAVE_EXOTIC_H (used by
eina_module.c). Since the other libs are all defined as HAVE_LIBNAME,
we're using HAVE_EXOTIC everywhere now.
SVN revision: 77816
it's pointless to have this and may cause problems or complex
configure.ac when we have libraries that use 'eet' during its compile
phase (like elementary generates its profile/configuration).
SVN revision: 77815
Now we always build the following memory pools statically:
- pass_through: calls malloc/free directly, useful to debug.
- chained_pool: default for ages.
- one_big: used by some embedded systems (should we remove?)
Removed:
- ememoa_fixed and ememoa_unknown: depends on a separate lib, not supported?
- buddy: nobody uses it?
NOTE: we do not need the src/modules/eina/mp/*/Makefile.am anymore
since they are statically built. But I'll keep these and the
references in src/modules/eina/mp/Makefile.am
SVN revision: 77792
Introduced --with-profile={dev,release} that will simplify how to set
build options of EFL.
NOTE-1: specific e17 benchmark is now gone, it will always be built
and is the default benchmark for eina. If we want to have a faster
benchmark in the future, just add a command line option for
eina_suite.
NOTE-2: valgrind build is broken as it needs -fPIC. Will get to it
later. Likely someone needs to revisit the eina mempools for valgrind
and other basic tools (eo? likely evas).
SVN revision: 77771
I can't be sure that distcheck is fixed as the check of eet is failing.
I've disable the run of the eina test for now as it is *very* long. I'll
re-enable it once eet check is running flawlessly
SVN revision: 76772