forked from enlightenment/efl
We want to introduce a new mechanism concerning the data of the Eo objects. The goal is to improve the memory management by defragmenting the memory banks used by the Eo objects. The first phase has been done by raster and consists in allocating the objects into a separate memory region that the one used by malloc. So now, we know where our objects are located. Now, moving objects means moving data of objects. The issue we have here is that a lot of data pointers are stored into data of other objects, e.g Evas Object data into lists for rendering... We need a way to reference the data and eo_data_get doesn't provide us that. So we need to improve the API for data extraction by requesting from the developer if the data will be stored or not. Five functions are supplied: - eo_data_scope_get: no referencing, the data pointer is no more used after exiting the function. - eo_data_ref: reference the data of the object. It means that while the data is referenced, the object cannot be moved. - eo_data_xref: reference the data of the object but for debug purpose, we associate the objects that references. Same behavior as eo_data_ref for non-debug. - eo_data_unref: unreference the data of an object. - eo_data_xunref: unreference the data of an object previously referenced by another object. I deprecated the eo_data_get function. Most of the time, eo_data_scope_get needs to be used. In the next patches, I changed the eo_data_get to the corresponding functions, according to the usage of the data pointer. The next step is to find all the places in the code where the data is stored but not yet referenced. This will be done by: - requesting from every object to unreference all data to other objects. - moving all the objects from one region to another - requesting from every object to rerefenrence the data. - debugging by hunting the segmentation faults and other weird creatures. |
||
---|---|---|
cmakeconfig | ||
data | ||
dbus-services | ||
doc | ||
licenses | ||
m4 | ||
old | ||
pc | ||
pkgbuild | ||
po | ||
spec | ||
src | ||
.arcconfig | ||
.gitignore | ||
AUTHORS | ||
COMPLIANCE | ||
COPYING | ||
ChangeLog | ||
Makefile.am | ||
NEWS | ||
README | ||
autogen.sh | ||
configure.ac |
README
EFL 1.7.99 ****************************************************************************** FOR ANY ISSUES PLEASE EMAIL: enlightenment-devel@lists.sourceforge.net ****************************************************************************** EFL is a collection of libraries for handling many common tasks a developer man have such as data structures, communication, rendering, widgets and more. VALGRIND DEPENDENCY: ------------------------------------------------------------------------------ EFL uses the concept of memory pools (mempool) and this will confuse valgrind memcheck tool. By using memory pool, the memory is still owned by EFL, then valgrind won't alert on memory leaks or use of unused memory. EFL will use memcheck.h from valgrind to declare its memory pools to valgrind, producing better debugging results. However valgrind is only available to limited platforms, making us hard to declare it a mandatory requirement. Based on --with-profile={dev,debug} valgrind will be used if available or will be issued a warning. You can force valgrind with --enable-valgrind, or disable it and the warning with --disable-valgrind. EFL does NOT link to valgrind libraries. Then there is NO runtime dependency on valgrind. BULLET PHYSICS DEPENDENCY: ------------------------------------------------------------------------------ EFL comes with EPhysics(a physics wrapper library) enabled by default, to build it the user must have BulletPhysics engine installed. More informations about BulletPhysics can be obtained in the upstream project web site at: http://bulletphysics.org. We have received many reports about BulletPhysics installation and distros packages in bad shape, some without even a package. If your distro doesn't ship a BulletPhysics package or you want to build it from source code follow the instructions below: * Required Packages: You should have cmake installed. Bullet comes with autotools and cmake build systems, do not use the autotools alternative, it's unstable, bogus and hasn't been maintained for quite some time. * Download the tarball from: http://code.google.com/p/bullet/downloads/list NOTE: the current supported version is 2.80 or greater. * Compiling and Installing: Uncompress it to(say) ~/bullet and: $ cd ~/bullet/build $ cmake .. -DBUILD_CPU_DEMOS=OFF -DBUILD_DEMOS=OFF -DBUILD_SHARED_LIBS=ON $ make $ sudo make install $ sudo ldconfig * Ubuntu Users: Alternatively ubuntu users have the option to install the BulletPhysics from our official EFL PPA: https://launchpad.net/~efl/+archive/trunk ------------------------------------------------------------------------------ COMPILING AND INSTALLING: ./configure make (do this as root unless you are installing in your users directories): make install EFL build is based on "profiles". It will default to "dev" for unreleased software and "release" for official tarballs. One can change it with --with-profile=NAME, where NAME is one of: * dev: extra checks useful to test software. * debug: superset of dev, with debug features and assert(). * release: optimizations and less checks so it runs faster. CRYPTOGRAPHIC SYSTEM: EFL officially uses "openssl" library to do signature, cipher and related. Alternatively one can use "gnutls" (some distros are strict about licenses and want gnutls instead of openssl) or disable it. One can change it with --with-crypto=NAME, where NAME is one of: "openssl", "gnutls" and "none".