Here are only 3 very basic test cases.
One is a dumb set/get to check that image objects can
be passed as clippers.
The other one is a pixel verification test with extremely
basic data (NEAREST scaling and just rectangles). It also
compares text clipping and masking.
The last one performs a very basic verification that masks
of masks work.
This reverts commit df3958bb89.
This is getting reverted because it broke building of Enlightenment. E
requires the Evas_Engine_Buffer header file for drawing mouse cursor
using the buffer engine.
Those really are internals shared between ecore and evas.
Considering ecore & evas are just part of EFL, and expedite
now doesn't even rely on these headers anymore, we can safely
remove them from the dist packages.
This will allow us to break this seemingly internal API/ABI.
Summary:
Until now, it was necessary to set global LDFLAGS and CFLAGS to allow
compiling (and linking) engines using OpenGL.
gl_generic used to complained about missing headers or unkown libraries.
A problem on OSX is that there is CGL (Apple's Core OpenGL) on which the whole system
relies on and GLX, when X11 is installed; and they cohabit together.
When gl_cocoa is enabled, gl_generic is now linked against CGL.
When it is not, gl_generic is compiled with and linked against GLX as a fallback.
@fix
Test Plan:
With --enable-cocoa: software_x11, opengl_x11 and opengl_cocoa are working as expected.
With --disable-cocoa: software_x11 and opengl_x11 are also working as expected.
No compiling nor linking problems have been issued.
Reviewers: cedric, raster, raoulh
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1723
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
.ply format is important for relation blender and EFl, because in blender exist only two mesh export API: bpy.ops.import_mesh.ply and bpy.ops.import_mesh.stl. One of them is necessary for .edc 3D generator. Which I writing now.
Sorry, it isn't like image loader. Refactoring of import/export will be soon.
Reviewers: Oleksander, artem.popov, Hermet, raster, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1544
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Some shader files (shd) were not included in EXTRA_DIST. This didn't break
the build because the .x file was correctly generated.
I guess the missing files in previous releases also had no impact because
the .h files would be generated and shipped.
Also generate the enum automagically. New shaders need to be added
to Makefile_Evas.am.
Like the evas drm engine the evas gl_drm engine now depends on eeze for
backlight. Make sure it is setup to find eeze like the drm engine already
does.
I have not been able to reproduce this myself but I have seen a build log where
the binary tries to link to libeo and fails due to the missing file.
A similar problem was "fixed" in 0e4b847deb, but
this really makes me wonder where the linking against eo comes from for cserve2
which is not using eo as far as I can see.
Various files form the tgv and 3d tests have been missing in EXTRA_DIST
and thus failing make distcheck. On the other hand we had duplicates in
the list. Clear this all up.
Add version param to context_create.
Add support for 1.1 contexts in the GL_X11 engine, and checks
for version in all other engines (return NULL).
Add API wrappers for all OpenGL-ES 1.1 APIs (normal and debug
modes).
Summary: The first version of .eet format is added. All changes due to discussion in D1307 are done.
Reviewers: artem.popov, se.osadchy, reutskiy.v.v, Hermet, raster, cedric, Oleksander
@feature
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1477
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This cleans up a lot of the build system. This makes everything
consistent, clean, less redundant and also fixes the issue of make clean
not cleaning up generated files.
Summary: The first version of .eet format is added.
Reviewers: Hermet, raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1307
While we are likely will keep the embedded copy for a while to avoid a really
new dependency we allow now to use the external liblz4. You need at least
revision r120 and a package that ships the pc file for it.
Personally I would like to get rid of it rather sooner than later due to the
security implications and a bunch of code we ship but have no idea about.
Reality is that it will need some time until this new lib is actually
packaged and shipped with releases for a a majority of people.
This patch was co-worked with Doug Newgard <scimmia22@outlook.com>
For some reason dummy links against libeo but doesn't depend on it.
I have no idea what dummy_slave is and why it behaves in such an odd way.
Maybe there's even a more serious issue somewhere, but for now, this seems
to fix build.
Summary: This is the first step to introduce a gl-drm backend.
Test Plan: "ecore evas" create with ecore_evas_gl_drm_new(). It creates "ecore evas" with gl_drm evas backend.
@feature
Reviewers: raster, Hermet, cedric, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1187
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
@fix
Segfault in wayland_egl engine is casused by illegal library linking.
Fix this by linking to GLESv2 and EGL libraries.
Test Plan: N/A
Reviewers: devilhorns, raster, cedric, Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1332
Summary:
This patch fixes following two problems:
1. libevas.so library has a dependency with ecore_drm if '--enable-drm' configure
option is given. This problem is due to 'EFL_INTERNAL_DEPEND_PKG([EVAS], [ecore-drm])'
in m4/evas_check_engine.m4 file. A dependency with ecore_drm should be moved to evas
drm engine not libevas.so. And also this macro makes an error while installation of evas.
$ make uninstall; ./configure --enable-drm; make && make install
2. missing ecore_drm dependency for evas drm engine.
USE_ECORE_DRM_LIBS macro should be used for building evas drm engine with ecore_drm
library. ECORE_DRM_LIBS macro doesn't have 'libecore_drm.la'. It is used for building
ecore_drm library.
@fix
Fixes T1473
Test Plan:
1. Remove EFL libraries in installation path: $ make uninstall
2. Configure with --enable-drm: $ ./autogen.sh --enable-drm
3. $ make && make install
4. Check module.so of evas drm engine whether it has a library dependency with ecore_drm
$ readelf -a $EFL_GIT/src/modules/evas/engines/drm/.libs/module.so | grep NEEDED
$ readelf -a $INSTALL_PATH/lib/evas/modules/engines/drm/v-1.11/module.so | grep NEEDED
Reviewers: stefan_schmidt, devilhorns, raster
Subscribers: cedric, torori
Differential Revision: https://phab.enlightenment.org/D1271
I'm not 100% sure this header is internal, but it depends on internal
headers, so it should either be internal or massively re-worked.
Anyhow, it has no business being installed until the includes are
fixed.
We use this functionality already from ecore_drm. The evas version does
not even use udev to acquire the device which means we could not support
hotplugging. The only missing feature was the capability check for
DUMB_BUFFER which I added to ecore_drm now.
This is the second iteration of this patch. Thsi time also taking expedite
runs of he evas drm engine in account.
This reverts commit 31ad73efa9.
Conflicts:
src/modules/evas/engines/drm/evas_engine.c
Revert this commit as these functions are needed to run evas engine
standalone (expedite) on drm
Summary:
This fixes a breakage in make dist.
There were a few stale entries from the recent removal of shader masking
code.
@fix
Thanks to Simotek for reporting
Reviewers: raster, cedric, Hermet
CC: simotek, cedric
Differential Revision: https://phab.enlightenment.org/D1125
Signed-off-by: Cedric BAIL <c.bail@partner.samsung.com>
We use this functionality already from ecore_drm. The evas version does
not even use udev to acquire the device which means we could not support
hotplugging. The only missing feature was the capability check for
DUMB_BUFFER which I added to ecore_drm now.
Summary:
currently, normal orientation tests are only added.
I'm going to add flipped orientation tests as well after I put related code in jpeg loader (currently it's not supported)
Reviewers: raster, cedric, jpeg
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D1098
Implement Alpha encoding, brute force way, but doesn't scan
all possibilities either (only based on average alpha).
RGB encoding is still entirely left to the rg-etc1 encoder.
T, H and Planar mode will come in the next commits.
@feature: Implement an ETC2 encoder from scratch for RGB8 and RGBA8
the declared t3d_scene api names are not matched exactly between header and code.
these name should be just "3d_scene"
and still there was a Evas_3D.h reference in evas Makefile.
Enable 3D features using --enable-evas-3d=yes when configuring.
APIs are exposed through Evas_3D.h.
Currently, evas-3d is being supported only on gl_x11 engine.
Conflicts:
src/lib/evas/Evas_Eo.h
LZ4HC has a higher compression ratio than LZ4 but basically the
same decompression speed.
The performance cost during encoding is actually still pretty low
considering how expensive ETC1 compression can be (even at medium
quality).
The new files (i386, sse3 and neon) are basically empty and fallback
to the C version. This is just to pave the way for full low-level
optimization... if someone has the time and skills to do it :)
Add both Alpha and RGBA template files.
The TGV file format is specifically created for Evas. It is designed to allow
region decompression and parallele decompression with a fast path for GPU that
do handle ETC1 compression. Plan for adding other compression method will come
later.
const have been added in object parameter of two legacy APIs to fit
Eolian generated files.
Since these functions retrieve information from object, it is logic that
the object would be const.
Actually, there is a very nice trick with BOX blur.
Pass BOX blur 3 times and you can approximate a GAUSSIAN
blur with up to 3% accuracy. This is way more than enough
for just a simple graphical effect.
So, despite the crappy quality of BOX blur, we should
optimize it a lot so we can replace large GAUSSIAN blurs
with series of BOX blurs instead.
Source: Wikipedia's page on box blur :)
This commit also moves around some duplicated definitions.
Prepare optimization paths for blur operations, as they are VERY
costly. This simple change, when using gcc -O3 flag, boosts
horizontal blur performance by > 50%, because STEP is 1 (and
so, memory accesses, increments, etc... are all very simple)
The objective is to have support for NEON, MMX, SSE, too, with
runtime detection.
Hmm, I forgot to add some .eo files to the EXTRA_DIST so they have not been
added inside the archive.
Eolian couldn't generate C files because of these missing files.
The first object that we generate with Eolian is Evas_Line, as it is a
simple one.
Two files are generated during build:
- the .eo.c contains the APIs definitions invoking Eo, the Eo functions
extracting the parameters and calling the hand written functions and
Eo structures to define the objects. These hand written functions are
located in e.g evas_object_line.c.
- the .eo.h contains the APIs and Eo prototyes.
We will continue with the other objects. If you note something wrong,
please update us asap:
daniel.zaoui@samsung.comyossi.kantor@samsung.com
Force render into an Ecore_Evas, and check that the pixels
are valid:
- Not all transparent (can't really happen)
- Not all black (since there's a black rect behind the text)
- All valid premultiplied values (A >= R,G,B)
Yes, it's a bit slow. But at least it really checks something :)
This is the simplest solution I can come up with for "mirror" effects.
Displacement maps are HARD to generate and use properly, since the buffer
size is unknown until runtime.
Even if we align the map to the text itself (using the padding information),
it's still hard to describe properly how to apply the displacement map, and
to generate it... So let's just add a simple flip operation.
Evas is an RGBA only engine, BUT we also use some alpha masks,
especially in the font rendering pipeline.
This commit adds basic support for alpha buffer operations
(blend and copy).
RGBA_Image can then point to either alpha-only data, if
its colorspace is grey.
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
Only import the C file for now.
Implement the following features:
- Shared Arrays
Store arrays of elements of fixed size in shm.
- Shared Mempool
Store random sized buffers in shm.
These buffers are indexed in a Shared Array and are
referred to using their index only.
- Shared Strings
Store strings in a shm in a way similar to Eina_Stringshare
(except strings are referred to using an int index).
- Include evas_cserve2_index.c to the compilation.
- Declare shared index functions in header file.
- Call init() and shutdown() on the shared index subsystem.
- Add find and foreach functions
This add finally support for JPEG 2000, but be aware that libopenjpeg
is very badly managed. There is currently only version 1.5.x that does
provide the right files, is usable by a third party and portable. You
can seriously forget any other version.
Objective: use common loaders from cserve2
Ideally evas_module should be a static library but it would
then require static/dynamic linking to too many modules unused
by cserve2 (eg. engines & savers)
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
NOTE: when using Evas_Object image preload infrastructure the GL texture
upload was uploaded from the main loop during the rendering stage. This
could lead to some frame drop during fast animation due to the time needed
to upload that texture.
This patch fix this problem by uploading a small texture quickly (16x16)
and waiting for going back to the main loop to be able to use the same GL
context from another thread to do the texture upload asynchronously without
blocking the main loop.
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
Now, Evas.h includes three new files:
- Evas_Eo.h: Eo API functions (functions defines, enums, base id).
- Evas_Legacy.h: contains the API functions related to objects
- Evas_Common.h: common data (structs, enums...) +
functions not related to objects.
This phase is needed for the EFL 1.8 release to disable Eo APIs if we
consider it is not enough mature to be used by applications.