Re: [E-devel] [RFC] Caching the result of evas_render_phase1_object_process
On Sun, Apr 13, 2008 at 9:52 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Sun, Apr 13, 2008 at 1:33 PM, Cedric BAIL [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL [EMAIL PROTECTED] wrote: Some of you already know, I am working on improving the speed of evas_render_phase1_object_process. The idea is that the list of active_object, and object to render will change much between to call to evas_render. I started by removing the use of evas_list and use a growing array of evas_object that is only freed on idle. This does bring only a small speed improvement. Then I started to cache the result evas_render_phase1_object_process and keep it alive except on layer change, show, hide and some color set case. On move and resize I wanted to just check if the state of stack of call to render_pre is still valid and call them accordingly. It's almost working. Just the resize is not. I don't understand why yet, but I can't make it work the same way as the move. Perhaps someone can help me on understanding this. So the code is attached for your fun, but don't commit it or it will break for sure :-) After some sleep I found where was the problem and here is an updated patch that finally work. It improve speed when you don't call evas_object_show/hide and don't use layer. Each time you call them, the cache will be droped in other case it will work. This improvement will complexify the task when we will one day enable render_pre for smart object as it make the assumption that no evas_object are modified during call to evas_render_updates_internal. Please review this patch and test it with your application. no time to test it now, but an overview is: - good, seems to break nothing (as you said); Good :-) - my general remarks to your coding style: try to avoid aligning variable declaration, it's not used in E and it causes patches to be dirtier than they need to (changes that just change this). I also dislike the return ; (with the space) ;-) - my general remarks about patches: try to avoid useless changes, like changing tabs-spaces and removing trailing white spaces, do it in separate patch before (now you have commit access, just commit these before you play!) Right :-) - evas_array seems very useful, make it available to evas as a whole! Just have it to take void * and it will do just fine. Also, I'd make the increase amount (16) configurable after the array is created (or provide an alternative constructor). Good idea, but as this are small functions and some are used a lot I like the idea of seeing them inlined. As there are more of this kind of function in Evas, small functions used a lot, I did move them after some profiling inside src/lib/include/evas_inline.x. This give us a little bit of speedup with only a small increase in library size. The function that could be inlined are : - evas_object_is_opaque - evas_event_passes_through - evas_object_is_visible - evas_object_clippers_is_visible - evas_object_is_in_output_rect - evas_object_is_active - evas_object_coords_recalc - evas_object_clip_recalc Are people interested by this kind of patch ? I would add evas_object_array_push to this list also. - I'd remove the calls to really do things (ie: e-engine.func-output_redraws_rect_del()) from _evas_render_phase1_object_process(), just call _evas_render_phase1_direct() after you built the array... I think this separation will be good and will no cause any damage to performance). OTH, if you want to have performance no matter what, then keep it as is by carry the should not cache flag (clean_them), in that case you'd not add to the array at all. I will look at this option and see if it really impact performance. as you can see, just minor things. It looks very great so far! PS: do you have the improvements in numbers? Would rock to present it as a chart, let's also make it public somewhere. (I regret for not doing that for the optimizations I did) Well as it's a cache mecanism, it doesn't really provide stable improvement. With expedite as was seeing a score between 490 and 540 on my computer and now it's between 490 and 610. With valgrind _evas_render_phase1_object_process only take 4% of my total time compared to the previous use of near 20%. I also think it should reduce the memory fragmentation of EFL based application, but I don't have number nor graph for this one. -- Cedric BAIL - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___
Re: [E-devel] [PATCH] more works and fixes for wallpaper fetcher
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 12 Apr 2008 09:02:09 +1000 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Mon, 17 Mar 2008 14:34:03 +0100 Massimiliano Calamelli [EMAIL PROTECTED] babbled: patch in cvs. The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] I'm very sorry, but my patch are older than actually cvs status, and using it E crashes. Honestly I didn't think that it could be applied, a long debate about backend libraries, and honeslty again Flickr support isn't a must-have feature, unluckly i find it only after finish works... I'm very sad, but i think it's better to revert my patch. Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIAy/EleGEL56NNP4RAviAAJ9GQxthgWD6TAjQBBQDZrhORHDe/ACeKqXo I4bB4i3ircUNtk1WuqDX99c= =PQCJ -END PGP SIGNATURE- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-04-14 07:09:17 -0700
Build log for Enlightenment DR 0.17 on 2008-04-14 07:09:17 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log engage http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Caching the result of evas_render_phase1_object_process
On Mon, Apr 14, 2008 at 11:55 AM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Sun, Apr 13, 2008 at 9:52 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
On Sun, Apr 13, 2008 at 1:33 PM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL [EMAIL PROTECTED] wrote:
- evas_array seems very useful, make it available to evas as a
whole! Just have it to take void * and it will do just fine. Also,
I'd make the increase amount (16) configurable after the array is
created (or provide an alternative constructor).
Good idea, but as this are small functions and some are used a lot I
like the idea of seeing them inlined. As there are more of this kind
of function in Evas, small functions used a lot, I did move them after
some profiling inside src/lib/include/evas_inline.x. This give us a
little bit of speedup with only a small increase in library size. The
function that could be inlined are :
- evas_object_is_opaque
- evas_event_passes_through
- evas_object_is_visible
- evas_object_clippers_is_visible
- evas_object_is_in_output_rect
- evas_object_is_active
- evas_object_coords_recalc
- evas_object_clip_recalc
Are people interested by this kind of patch ? I would add
evas_object_array_push to this list also.
Because code is better than discussion, here is a patch that does
exactly that. Comment are welcome :-)
--
Cedric BAIL
diff --git a/src/lib/canvas/evas_clip.c b/src/lib/canvas/evas_clip.c
index bd7dd54..dfc3e4f 100644
--- a/src/lib/canvas/evas_clip.c
+++ b/src/lib/canvas/evas_clip.c
@@ -2,57 +2,6 @@
#include evas_private.h
void
-evas_object_clip_recalc(Evas_Object *obj)
-{
- int cx, cy, cw, ch, cvis, cr, cg, cb, ca;
- int nx, ny, nw, nh, nvis, nr, ng, nb, na;
-
- if (obj-layer-evas-events_frozen 0) return;
-// if (!obj-cur.clipper-cur.cache.clip.dirty) return;
- evas_object_coords_recalc(obj);
- cx = obj-cur.geometry.x; cy = obj-cur.geometry.y;
- cw = obj-cur.geometry.w; ch = obj-cur.geometry.h;
- cx = obj-cur.cache.geometry.x; cy = obj-cur.cache.geometry.y;
- cw = obj-cur.cache.geometry.w; ch = obj-cur.cache.geometry.h;
- if (obj-cur.color.a == 0) cvis = 0;
- else cvis = obj-cur.visible;
- cr = obj-cur.color.r; cg = obj-cur.color.g;
- cb = obj-cur.color.b; ca = obj-cur.color.a;
- if (obj-cur.clipper)
- {
-// this causes problems... hmmm
-// if (obj-cur.clipper-cur.cache.clip.dirty)
- evas_object_clip_recalc(obj-cur.clipper);
- nx = obj-cur.clipper-cur.cache.clip.x;
- ny = obj-cur.clipper-cur.cache.clip.y;
- nw = obj-cur.clipper-cur.cache.clip.w;
- nh = obj-cur.clipper-cur.cache.clip.h;
- nvis = obj-cur.clipper-cur.cache.clip.visible;
- nr = obj-cur.clipper-cur.cache.clip.r;
- ng = obj-cur.clipper-cur.cache.clip.g;
- nb = obj-cur.clipper-cur.cache.clip.b;
- na = obj-cur.clipper-cur.cache.clip.a;
- RECTS_CLIP_TO_RECT(cx, cy, cw, ch, nx, ny, nw, nh);
- cvis = cvis * nvis;
- cr = (cr * (nr + 1)) 8;
- cg = (cg * (ng + 1)) 8;
- cb = (cb * (nb + 1)) 8;
- ca = (ca * (na + 1)) 8;
- }
- if ((ca == 0) || (cw = 0) || (ch = 0)) cvis = 0;
- obj-cur.cache.clip.x = cx;
- obj-cur.cache.clip.y = cy;
- obj-cur.cache.clip.w = cw;
- obj-cur.cache.clip.h = ch;
- obj-cur.cache.clip.visible = cvis;
- obj-cur.cache.clip.r = cr;
- obj-cur.cache.clip.g = cg;
- obj-cur.cache.clip.b = cb;
- obj-cur.cache.clip.a = ca;
- obj-cur.cache.clip.dirty = 0;
-}
-
-void
evas_object_clip_dirty(Evas_Object *obj)
{
Evas_List *l;
@@ -76,18 +25,6 @@ evas_object_recalc_clippees(Evas_Object *obj)
}
int
-evas_object_clippers_is_visible(Evas_Object *obj)
-{
- if (obj-cur.visible)
- {
- if (obj-cur.clipper)
- return evas_object_clippers_is_visible(obj-cur.clipper);
- return 1;
- }
- return 0;
-}
-
-int
evas_object_clippers_was_visible(Evas_Object *obj)
{
if (obj-prev.visible)
diff --git a/src/lib/canvas/evas_events.c b/src/lib/canvas/evas_events.c
index c31ac15..3eb6346 100644
--- a/src/lib/canvas/evas_events.c
+++ b/src/lib/canvas/evas_events.c
@@ -1,24 +1,6 @@
#include evas_common.h
#include evas_private.h
-int
-evas_event_passes_through(Evas_Object *obj)
-{
- if (obj-layer-evas-events_frozen 0) return 1;
- if (obj-pass_events) return 1;
- if (obj-parent_cache_valid) return obj-parent_pass_events;
- if (obj-smart.parent)
- {
- int par_pass;
-
- par_pass = evas_event_passes_through(obj-smart.parent);
- obj-parent_cache_valid = 1;
- obj-parent_pass_events = par_pass;
- return par_pass;
- }
- return 0;
-}
-
static Evas_List *
_evas_event_object_list_in_get(Evas *e, Evas_List *in, Evas_Object_List *list, Evas_Object *stop, int x, int y, int *no_rep)
{
diff --git a/src/lib/canvas/evas_object_main.c b/src/lib/canvas/evas_object_main.c
index e5e5fde..e19bebf 100644
--- a/src/lib/canvas/evas_object_main.c
+++ b/src/lib/canvas/evas_object_main.c
@@ -302,53 +302,6 @@ evas_object_render_pre_effect_updates(Evas_List *updates, Evas_Object *obj, int
Re: [E-devel] [PATCH] updated: three new edje embryo functions
On Sun, Apr 13, 2008 at 7:42 PM, Peter Wehrfritz [EMAIL PROTECTED] wrote:
Gustavo Sverzut Barbieri schrieb:
Maybe it will not impact things. The problem with these calls is that
they would collide with Edje internal states, getting these
inconsistent. But since Edje does not handle any layer/stack-related
information in their states, maybe this is no problem, in this case
just add the call to edje C api (edje_object_part_{raise,lower}()) and
expose it from embryo.
I don't think it is a good idea to have those functions in the edje c
api. The application should change directly the theme. That's why there
isn't a edje_object_part_state_set() function.
While I'm unsure whenever to have or not this function exported, this
is different from what you said: part_state_set() can be done with
signals, while there are no means to reorder the objects from edje,
neither from states or code. Maybe the reason to not have this known
by someone (raster?), maybe it was just left out due out-of-time, in
that case we could add this to Edje states and use signals to trigger
changes.
Lars: what's your motivation to use this? maybe this can give us some light.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Caching the result of evas_render_phase1_object_process
On Mon, Apr 14, 2008 at 12:38 PM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Mon, Apr 14, 2008 at 11:55 AM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Sun, Apr 13, 2008 at 9:52 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
On Sun, Apr 13, 2008 at 1:33 PM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL [EMAIL PROTECTED]
wrote:
- evas_array seems very useful, make it available to evas as a
whole! Just have it to take void * and it will do just fine. Also,
I'd make the increase amount (16) configurable after the array is
created (or provide an alternative constructor).
Good idea, but as this are small functions and some are used a lot I
like the idea of seeing them inlined. As there are more of this kind
of function in Evas, small functions used a lot, I did move them after
some profiling inside src/lib/include/evas_inline.x. This give us a
little bit of speedup with only a small increase in library size. The
function that could be inlined are :
- evas_object_is_opaque
- evas_event_passes_through
- evas_object_is_visible
- evas_object_clippers_is_visible
- evas_object_is_in_output_rect
- evas_object_is_active
- evas_object_coords_recalc
- evas_object_clip_recalc
Are people interested by this kind of patch ? I would add
evas_object_array_push to this list also.
Because code is better than discussion, here is a patch that does
exactly that. Comment are welcome :-)
I like it. It could be dangerous for externally used calls, but for
those exported in evas_private.h, it makes sense.
I just think that some functions should be split in 2 parts: common
and corner, just the common part should be inline, while the corner,
usually bigger, should be regular function defined in evas_private.h.
This would avoid code growing too much while giving us the fast common
path. For example: evas_array_push will not have to realloc most of
times, so it should be in another function:
// defined in some evas_private.c
void
_evas_array_grow(Evas_Array *array)
{
void *tmp;
unsigned int total;
total = array-total + 16;
tmp = realloc(array-obj, sizeof(void*) * total);
if (!tmp) return;
array-obj = tmp;
array-total = total;
}
// defined in some evas_private.h
static inline void
evas_array_append(Evas_Array *array, void *data)
{
if (array-count == array-total) // maybe use unlikely() here, see
gcc info, builtin_expect
_evas_array_grow(array);
array-obj[array-count++] = data;
}
Also, for _internal_ things I really dislike null-pointer checking: we
should never have one, if we do then we are buggy and must crash ASAP
to catch the error sooner. Just entry-point should do these checks to
make library robust.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] evas_object_stack_above broken with clippers?
http://bugs.enlightenment.org/show_bug.cgi?id=444
Steps to reproduce
===
1 Download the source attached source code.
2 Compile with gcc -g -o example `pkg-config --cflags --libs evas ecore-evas
edje` main.c
3 Execute ./example
Actual results
==
Two rectangles are drawn, a smaller red rectangle over a blue rectangle.
Expected results
Two rectangles are be drawn, the smaller red rectangle *under* a blue
rectangle.
Additional notes
Commenting the call to evas_object_clip_set solves the issue, the clipper
(white rectangle) stays on top.
I updated, recompiled and installed all the libraries involved right before I
submitted this bug.
#include stdlib.h
#include stdio.h
#include Evas.h
#include Ecore.h
#include Ecore_Evas.h
#include Edje.h
//The pointer to a canvas wrapper
Ecore_Evas *ecore_evas = NULL;
//The pointer to an Evas canvas
Evas *evas = NULL;
//The pointer to a given Edje object
Evas_Object *edje = NULL;
//Width and height for resizing Evas/Edje objects
Evas_Coord width, height;
//Pointers to Ecore handlers
Ecore_Event_Handler* close = NULL;
int main() {
//Control that the libraries are properly initialized
if (!ecore_init()) return EXIT_FAILURE;
if (!ecore_evas_init()) return EXIT_FAILURE;
if (!edje_init()) return EXIT_FAILURE;
//Check the canvas wrapper (800x600 X11 window) is created correctly
ecore_evas = ecore_evas_software_x11_new(NULL, 0, 0, 0, 800, 600);
if (!ecore_evas) return EXIT_FAILURE;
//We set some window attributes and make the wrapper visible
ecore_evas_title_set(ecore_evas, Example Application);
ecore_evas_name_class_set(ecore_evas, testapp, Testapp);
ecore_evas_show(ecore_evas);
//Get the pointer to the canvas and add tan object
evas = ecore_evas_get(ecore_evas);
Evas_Object *blue;
blue = evas_object_rectangle_add(evas);
evas_object_color_set(blue,0,0,255,255);
evas_object_resize(blue,500,500);
evas_object_move(blue,0,0);
evas_object_show(blue);
Evas_Object *red;
red = evas_object_rectangle_add(evas);
evas_object_color_set(red,255,0,0,255);
evas_object_resize(red,100,100);
evas_object_move(red,25,25);
evas_object_show(red);
evas_object_stack_above(red,blue);
Evas_Object *clipper;
clipper = evas_object_rectangle_add(evas);
evas_object_color_set(clipper,255,255,255,255);
evas_object_resize(clipper,250,250);
evas_object_move(clipper,50,50);
evas_object_show(clipper);
evas_object_clip_set(blue,clipper);
evas_object_stack_above(clipper,red); //does not work! red stays on top.
//Starting the main application loop
ecore_main_loop_begin();
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] updated: three new edje embryo functions
On Mon, Apr 14, 2008 at 02:29:06PM -0300, Gustavo Sverzut Barbieri wrote:
On Sun, Apr 13, 2008 at 7:42 PM, Peter Wehrfritz [EMAIL PROTECTED] wrote:
Gustavo Sverzut Barbieri schrieb:
Maybe it will not impact things. The problem with these calls is that
they would collide with Edje internal states, getting these
inconsistent. But since Edje does not handle any layer/stack-related
information in their states, maybe this is no problem, in this case
just add the call to edje C api (edje_object_part_{raise,lower}()) and
expose it from embryo.
I don't think it is a good idea to have those functions in the edje c
api. The application should change directly the theme. That's why there
isn't a edje_object_part_state_set() function.
While I'm unsure whenever to have or not this function exported, this
is different from what you said: part_state_set() can be done with
signals, while there are no means to reorder the objects from edje,
neither from states or code. Maybe the reason to not have this known
by someone (raster?), maybe it was just left out due out-of-time, in
that case we could add this to Edje states and use signals to trigger
changes.
Lars: what's your motivation to use this? maybe this can give us some light.
I have a set of buttons with a small overlap, all made with edje. On
mouse,in event I want the active button to become the topmost part.
I first thought about just emitting a signal from edje on mouse,in to
an event handler in C that would use edje_object_part_object_get and
then evas_object_raise, but I really wanted the part raising in edje so
I only had to take care of the actual event handling in C (the actual
button click).
The part_lower was mostly added for completion :)
It would be very nice to have some way to reorder the objects from edje.
Regards
Lars Munch
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] R: Re: [PATCH] updated: three new edje embryo functions
- Peter Wehrfritz [EMAIL PROTECTED] ha scritto:
Gustavo Sverzut Barbieri schrieb:
Maybe it will not impact things. The problem with these calls is
that
they would collide with Edje internal states, getting these
inconsistent. But since Edje does not handle any
layer/stack-related
information in their states, maybe this is no problem, in this case
just add the call to edje C api (edje_object_part_{raise,lower}())
and
expose it from embryo.
I don't think it is a good idea to have those functions in the edje c
api. The application should change directly the theme. That's why
there
isn't a edje_object_part_state_set() function.
Peter
You can also use edje_edit_part_restack_above(), but I totally agree with Peter.
Dave
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save
$100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
