You can try it by passing --enable-fixed-point to the configure. It
will produce an ABI/API compatible Edje library that use internally
Eina_F32p32 instead of double. It will load Eina_F32p32 instead of
double from eet file (thanks to eet ability to convert them on the
fly), so edje file are compatible between fixed point and floating
point version.
This patch touch almost all internal calc of Edje, I did test it with
elementary_test, enlightenment and all my test apps, but it could
certainly break some of your preferred Edje file. If you see any
unexpected behaviour please report them to me as soon as possible.
Note: For devs, I put few macros in edje_private.h that should now
be used when doing calc in Edje, please use them so that Fixed Point
doesn't break in the futur.
SVN revision: 44323
Since we are on a freeze, the patch goes on updated to current svn, but without changing its API. After the freeze some things will be added, and some will change :)
SVN revision: 43302
- Edje_Real_Part use less memory.
- Edje_Real_Part and Edje_Real_Part_State now use a mempool.
- When both param1 and param2 are the same, only recalc param1.
- Don't compute Edje_Real_Part more than one time per edje_recalc_do.
SVN revision: 41771
if sfont=something was given to _edje_text_class_font_get(), sfont
might be untouched there and old pointer was being freed, resulting in
double free. So make sure we're using the correct pointer there.
SVN revision: 41714
WARNING: THIS CAN CAUSE RENDERING GLITCH AND OTHER WEIRD BEHAVIOUR WITH
YOUR EDJE FILE. PLEASE REPORT ANY ALIEN STUFF.
Note: This patch cache the result of _edje_part_recalc_single, until
any relative part are moved, the object is resized or some property
are changed (like during text set or color class set).
Note: Be carefull when you call edje_object_size_min_restricted_calc,
it's really an inderect heavy user of _edje_part_recalc_single and
I wasn't able to bring it down.
Note: This patch use more RAM, around 480 bytes per Edje state, so I
don't recommand using it on a Desktop with a lot of CPU power.
SVN revision: 41663
Note: It doesn't really impact edje memory foot print yet. But in
the plan to do a computation cache inside edje, this structure
will be used a lot (I am planning to do this feature at some point,
but no ETA yet, and be reassured it will be optionnal so we can
choose between CPU load or memory load).
Note: As I was looking for similar area of improvements,
Edje_Part_Description could really use an union to reduce it's size,
but as we load this structure directly from an Eet file, we need
union in Eet first. And this should be part of a comming Edje file
format break.
SVN revision: 41652
Often requested for animations that want to grow or shrink text
quickly. This is a faster alternative to using geometry with rel1/rel2
and "text.fit: 1 1;" since it does not need to figure out which size
fits better into that object.
I tested and it does not seem to introduce any regression. Also
checked with scale and text_class variations.
SVN revision: 38958
as reported, elicity triggers an infinite loop by calling
edje_object_part_geometry_get(), which in turns calls
_edje_recalc_do() which in turns calls the elicit code that requests
edje_object_part_geometry_get() and since it's still marked as
"dirty", it enters the loop...
the real fix is just the move of ed->dirty = 0; before calling
recalcs, but I also unmarked object as need_recalculate so we can even
avoid requesting object to recalculate from evas.
SVN revision: 38139
This makes use of new Evas_Smart_Class calculate() callback to
postpone calculations until render time, possible saving lots of
calculations to happen.
It is another try, with Cedric's changes to force recalculations when
requried (ie: just before doing some edje_object_*_get()), let's see
if this one solve found issues.
SVN revision: 37620
them from being put in the evas_render_update phase.
I did extensively test this patch since a few month and didn't notice any
bug with it in my apps, nor in E. But please report anything that goes wrong
for you after this version.
SVN revision: 35944
Edje is tricky, it's event processing is too weird and Cedric's
changes to make it work are not working as expected. Edje freezes
itself while processing signals, but in mouse down cb it forces
recalculate, which seems was previously ignored, but now they are not.
We should look at how to fix this and then re-apply this patch.
SVN revision: 35908
:)... this allows e etc. to adapt to massivelyt different dpi screens with
slickness that even svg can't get to... why? you scale just what NEEDS
scaling (text, button sizes, and other limiting elements). other bits like
borders, padding etc. can remain pixel-perfect and thus the look is amazing.
pixel-perfect drawing with scalable adapting.
SVN revision: 35895
Some people is using it for some time now without problems, so I'm
adding it to SVN to get some broader use. Remember to recompile ALL
libraries that depend on Evas as it will change the
EVAS_SMART_CLASS_VERSION and old classes will fail to load.
This will also change Edje so it will postpone _edje_recalc() to
render time, calculate() callback, however some methods will force
early recalculation.
SVN revision: 35860
Edje tries to copy original style to font provided by text_class if
this have no style.
However code was supposing that text_class font always had more than
one occurrence, these separated with ',' and did not check if this is
not the case, so "e = strchr(',', tok);" was returning NULL and all
the math were using negative values.
The fix now does the proper checking, avoid one useless alloca() and
the respective copy, also doing the copies with memcpy() since sizes
are already known.
Refactory was done to make code simpler and also avoid having it
copied 3 times.
SVN revision: 33869
Check if values actually differ before interpolating them, this will
avoid useless math for (x1 - (x1 - x2) * p) when x1 and x2 are equal.
Also don't interpolate values that doesn't make sense to the part,
like color2 and color3 for non-text.
TODO: Refactor edje part description into more object-oriented
fashion, with a struct with just the common parts followed by an union
of structs for special objects, these would contain specific bits for
each part type. This would save us a bit of memory and then we can
more easily refactor code isolating common and specific parts, making
code smaller and easier to handle.
SVN revision: 33861
My last patch fixed the compile problem, but really, we should use the
same struct for things that look/work the same, like rectangle,
position, etc.
This new patch brings that change back and add some named structs
(also typedef'ed so it conforms to E naming schema).
This commit just changes the header and adds an example of
benefit. Later I'll provide a more intrusive patch that reorganize
structures to make even better use of this.
SVN revision: 33860
The "simple" block:
p3 = p1;
was doing an implicity memcpy() responsible for about 1% of processing
time when no animation happens.
Patch by Cedric BAIL.
SVN revision: 33858
Due my last change, the code was broken by edjes without a group
min/max, this happens because edje_object_size_max_get() returns
100000 for these objects, and this was being used as object maximum
size.
Current fix is a hack: just check for this value, now known as
EDJE_INF_MAX_*, but the real solution would be to return 0 (or -1) and
check for it in other parts of the code, but it's harder to get right.
SVN revision: 32123
If you have a SWALLOW part taking the whole window and then swallow an
object with max set using edje_extern_object_max_size_set() it will
not take effect due the comparison of ep->swallow_params.max.w < -1
(desc->max.w is -1 in this case).
SVN revision: 32029
This avoid crashes with buggy edje files: if you forget to specify
type: RECT and don't provide any "images.image" in edje, it crashes.
SVN revision: 31689
These can be used to automatically swallow in another group from the same file.
Parts within child groups can be referred to by a ':' separated 'full path' of
part names. Any API functions that take a part name will now accept a full path
also.
Signals emitted by child objects will be repeated up to the parents with the
source changed to be the path relative to the receiving object. E.g in the
example below, a mouse moving over the lower light green rectangle would result
in the parent object recieving a "mouse,move" signal with source "bot:inner".
**** NEW RESTRICTION **** part names should no longer include a ':' character.
This is not yet enforced by edje_cc, but will cause the part to be inaccessible
from the API.
Example EDC:
collections {
group {
name: "parent";
parts {
part {
name: "top";
type: GROUP;
source: "child";
description {
state: "default" 0.0;
rel2.relative: 1 0.5;
}
}
part {
name: "bot";
type: GROUP;
source: "child";
description {
state: "default" 0.0;
rel1.relative: 0 0.5;
}
}
}
}
group {
name: "child";
parts {
part {
name: "base";
type: RECT;
description {
state: "default" 0.0;
color: 160 208 8 255;
}
}
part {
name: "inner";
type: RECT;
description {
state: "default" 0.0;
rel1.offset: 10 10;
rel2.offset: -11 -11;
color: 210 228 76 255;
}
}
}
}
}
SVN revision: 30087
Cedric BAIL
Carsten Haitzler
Sebastian Dransfeld
Iván Briano
Vincent Torri
Gustavo Sverzut Barbieri
Viktor Kojouharov
doursse
Peter Wehrfritz
rephorm