Should be more portable and work with C++.
NOTE: I still see an aliasing break in eina_value_pset, but wasn't
able to figure how to solve it.
SVN revision: 67065
eina value is a generic value storage, it's quite efficient to space
(16 bytes) and speed (inlines for basic types).
It's basically a structure describing how to manage memory
(Eina_Value_Type), with default implementation for char, short, int,
long, int64_t (and unsigned variants), float, double, stringshare and
string.
If a type 'value_size' is smaller than 8 bytes, it's stored
inline. Otherwise a value is allocated and managed.
Most of the methods are inline, with special handling for char, short,
int... Then no extra calls are made, allowing the compiler to optimize
them.
For array of a single type it is recommend to use Eina_Value_Array, as
it will efficiently store and access members (just a char if subtype
is EINA_VALUE_TYPE_CHAR, etc).
It can copy itself, compare itself. Including arrays.
It would be nice to have something that converts between EET and this.
SVN revision: 67035
events).
Add big fat NB wrt potential 'hack' (works around screen garbage on
resize).
Add evas damage rectangle on resize.
Do surface_damage before surface_attach.
Prevent compositor crash on resize by checking width/height <= 0.
Don't do a resize of the ecore_evas unless the event matches.
SVN revision: 67013
It is an inline array, that is, the members are actually in the
allocated buffer, as opposed to a pointer to its data.
It can be used to manage array of integers, floats or other structures
without fragmenting memory.
The lookups should be fast as memory is linear, then CPU prefetch can
kick in and bring data to cache before it's used.
SVN revision: 67003
Add variable to store what button was pressed (part of focus issue
fixes).
Fix focus handling (see comments about wayland pointer focus).
SVN revision: 66994
On macosx i386, that code fails because even though __VEC__ is defined,
the compiler doesn't understand the 'vector' keyword (that macro is
irrelevent here). So there was no way to make evas compile for ppc if
altivec was not supported by the compiler.
SVN revision: 66966
This is so that future scripts will still work with old libraries,
and lets us add the "host can provide Lua API" feature soon.
Also some more comments.
SVN revision: 66961
We must check for cflags/ldflags and evil/escape libs before looking
for headers (like sys/mman.h) because they could be provided by one
of those libs. We must also set CFLAGS/LDFLAGS/LIBS variables to the
EINA_CFLAGS/EINA_LDFLAGS/EINA_LIBS vars so they get picked up properly
SVN revision: 66954
NOTE: it's just a partial revert of previous patch by
raster. Without that, some text were flickering going
on and off for sometime. I didn't take the time to
understand why, but by forcing the recalc it permanently
solve the issue.
SVN revision: 66903
NOTE: I am still wondering what is the cost difference between
forcing a request to eet_open and calling stat. If someone has some
time to benchmark, feel free to do so and report on e-devel ml.
SVN revision: 66902
* This feature requires libOSMesa to be installed.
One caveat with OSMesa is that a surface config (ie. Depth Buffer and etc)
is associated with a context rather than a surface, which is the case
in EvasGL. So for now, when a user specifies a surface config, it gets
associated with the first context that the surface does a make current to.
For typical usage case, this shouldn't be a prolem. Will need to fix it
eventually.
SVN revision: 66896
It is possible that several process want to show same canvas.
For support this, I changed Ecore buffer canvas to server(socket)
If some application want to show this canvas,
it create plug image object.
SVN revision: 66892
Cedric BAIL
Christopher Michael
Daniel Juyung Seo
Gustavo Sverzut Barbieri
Youness Alaoui
ChunEon Park
Sebastian Dransfeld
David Walter Seikel
Boris Faure
Mike Blumenkrantz
Carsten Haitzler
Sung Park
Jiyoun Park