Re: [E-devel] RFC: evas smart pre_render
On Wed, Aug 20, 2008 at 5:06 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > Guys, > > Batch of patches covering most of SVN. I changed it a bit, but on top > of Cedric changes. > > New version provides a need_recalculate flag for smart objects, this > flag, when set and SmartObject provides calculate(), will call this > function before doing any work on render. If not provided, this flag > will be untouched. There is also a way for users to call calculate > themselves, this is evas_object_smart_calculate(), that will help and > unset need_calculate. > > With this change, we can even avoid the dirty flags spread all over > our code, replacing them with need_recalculate. This also gives a > common name, calculate, avoiding things like reconfigure, recalc, ... > > So far edje makes minimal use of it, others don't use it at all. > Python bindings are exporting that to its users, but no example code > is provided yet. > > TODO: we add objects to e->calculate_objects, but do not remove then > until render phase. If you have a need_render_set, unset, then set > again, you'll end with 2 entries for that object in the array. It's > not a big problem, because we check for need_recalculate before > calling the function and this flag is unset after the first call. > > As Cedric, I'm using e17 with this patch and it works nicely. Please > comment on it, let's try to include it soon. All in SVN now, remember that you must recompile ALL libraries/apps that create Smart Objects (edje, etk, ewl, python-efl, ...). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
Gustavo wrote: > Guys, > > Batch of patches covering most of SVN. I changed it a bit, but on top > of Cedric changes. > > New version provides a need_recalculate flag for smart objects, this > flag, when set and SmartObject provides calculate(), will call this > function before doing any work on render. If not provided, this flag > will be untouched. There is also a way for users to call calculate > themselves, this is evas_object_smart_calculate(), that will help and > unset need_calculate. > > With this change, we can even avoid the dirty flags spread all over > our code, replacing them with need_recalculate. This also gives a > common name, calculate, avoiding things like reconfigure, recalc, ... > > Another possibility for the name might be "update". That's sometimes used as indicating calculations to be done related to render time somehow. > So far edje makes minimal use of it, others don't use it at all. > Python bindings are exporting that to its users, but no example code > is provided yet. > > TODO: we add objects to e->calculate_objects, but do not remove then > until render phase. If you have a need_render_set, unset, then set > again, you'll end with 2 entries for that object in the array. It's > not a big problem, because we check for need_recalculate before > calling the function and this flag is unset after the first call. > > As Cedric, I'm using e17 with this patch and it works nicely. Please > comment on it, let's try to include it soon. > > Click to lower your debt and consolidate your monthly expenses. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m2bkdW2vXfH56ZO9I0Z8C4dap3cWqYswiR0ICgOgrosXQYk/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
Guys,
Batch of patches covering most of SVN. I changed it a bit, but on top
of Cedric changes.
New version provides a need_recalculate flag for smart objects, this
flag, when set and SmartObject provides calculate(), will call this
function before doing any work on render. If not provided, this flag
will be untouched. There is also a way for users to call calculate
themselves, this is evas_object_smart_calculate(), that will help and
unset need_calculate.
With this change, we can even avoid the dirty flags spread all over
our code, replacing them with need_recalculate. This also gives a
common name, calculate, avoiding things like reconfigure, recalc, ...
So far edje makes minimal use of it, others don't use it at all.
Python bindings are exporting that to its users, but no example code
is provided yet.
TODO: we add objects to e->calculate_objects, but do not remove then
until render phase. If you have a need_render_set, unset, then set
again, you'll end with 2 entries for that object in the array. It's
not a big problem, because we check for need_recalculate before
calling the function and this flag is unset after the first call.
As Cedric, I'm using e17 with this patch and it works nicely. Please
comment on it, let's try to include it soon.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Index: edje/src/lib/edje_util.c
===
--- edje/src/lib/edje_util.c(revision 35583)
+++ edje/src/lib/edje_util.c(working copy)
@@ -715,6 +715,10 @@
ed = _edje_fetch(obj);
if ((!ed) || (!part)) return NULL;
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp) return NULL;
return rp->object;
@@ -748,6 +752,10 @@
if (h) *h = 0;
return;
}
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp)
{
@@ -828,6 +836,10 @@
ed = _edje_fetch(obj);
if ((!ed) || (!part)) return NULL;
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp) return NULL;
if (rp->part->type == EDJE_PART_TYPE_TEXT)
@@ -855,6 +867,10 @@
ed = _edje_fetch(obj);
if ((!ed) || (!part)) return;
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp) return;
if (rp->part->type != EDJE_PART_TYPE_SWALLOW) return;
@@ -1021,7 +1037,7 @@
rp->swallow_params.max.w = 0;
rp->swallow_params.max.h = 0;
rp->edje->dirty = 1;
- _edje_recalc(rp->edje);
+ _edje_recalc_do(rp->edje);
return;
}
}
@@ -1039,6 +1055,10 @@
ed = _edje_fetch(obj);
if ((!ed) || (!part)) return NULL;
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp) return NULL;
return rp->swallowed_object;
@@ -1088,6 +1108,10 @@
if (maxh) *maxh = 0;
return;
}
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
if (ed->collection->prop.max.w == 0)
{
/* XXX TODO: convert maxw to 0, fix things that break. */
@@ -1125,7 +1149,7 @@
ed->dirty = 1;
pf = ed->freeze;
ed->freeze = 0;
- _edje_recalc(ed);
+ _edje_recalc_do(ed);
ed->freeze = pf;
}
@@ -1187,7 +1211,7 @@
ok = 0;
ed->dirty = 1;
- _edje_recalc(ed);
+ _edje_recalc_do(ed);
if (reset_maxwh)
{
maxw = 0;
@@ -1291,6 +1315,10 @@
if (val_ret) *val_ret = 0;
return "";
}
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp)
{
@@ -1335,6 +1363,10 @@
ed = _edje_fetch(obj);
if ((!ed) || (!part)) return EDJE_DRAG_DIR_NONE;
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp) return EDJE_DRAG_DIR_NONE;
if ((rp->part->dragable.x) && (rp->part->dragable.y)) return
EDJE_DRAG_DIR_XY;
@@ -1399,6 +1431,10 @@
if (dy) *dy = 0;
return;
}
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp)
{
@@ -1464,6 +1500,10 @@
if (dh) *dh = 0;
return;
}
+
+ /* Need to recalc before providing the object. */
+ _edje_recalc_do(ed);
+
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp)
{
@@ -1522,6 +1562,10 @@
if (dy)
Re: [E-devel] RFC: evas smart pre_render
On Tue, Aug 19, 2008 at 11:44 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 18, 2008 at 6:24 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
>> On Sat, Aug 16, 2008 at 3:15 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>>> Just to make it clear what I think about this: This kind of thing is
>>> something that really needs to be done, one way or another. :)
>>>
>>> Some time back, I thought about having the edje recalc function called
>>> by smart class render-pre/post funcs, and these funcs I wanted to be called
>>> by the obj's internal render-pre/post ones as this would be useful for
>>> creating
>>> semi-custom, stateful, objs that rendered to image buffers (possibly native
>>> surfaces). But I saw that there were problems with that due to the very
>>> kinds
>>> of things you mention, the events system and possibly other things, as I
>>> mentioned to Cedric once here.
>>> You could have an additional smart class func, say a "calculate" one and
>>> then do as you suggest.. but the main issue here is whether this kind of
>>> smart
>>> class specific approach is the "best" way to deal with this kind of general
>>> issue.
>>> I've mentioned two other possible ways to deal with this in a more
>>> generic
>>> manner - for example an ecore_evas based one akin to what's done with
>>> sub-canvases
>>> (which is useful for those), or a more 'evas only' one akin to what you
>>> have here
>>> but using user supplied callbacks. There are other possibilities.. evas
>>> could
>>> expose an EVAS_RENDER_EVENT and have callbacks one can add for such, called
>>> prior
>>> to the internal evas-render loop... and other possibilities.
>>
>>> I don't know what might be best.. just that this is something needed but
>>> that needs more thought, some experimenting, etc. Maybe raster, nathan,
>>> hisham,
>>> and others can give more feedback on this - maybe your proposal *is* the
>>> best
>>> way to deal with this general issue, but it won't hurt to consider other
>>> possible
>>> ways if they have potentially wider applicability. :)
>>
>> Ok, here is a patch that improve the speed for evas part of Gustavo
>> work. I did rename the callback to calculate. Regarding if it's the
>> best way, that I don't know, but it's easy to implement on both side
>> and fast.
>>
>> Between the edje patch is currently not correct as many getter expect
>> the underlying object to be calculated. If you apply the attached
>> patch (not really a smart patch) you will see that many user of edje
>> expect it to be calculated at some point.
>
> And here is the edje patch. It did fix E17 use of edje and I didn't
> see any problem. But please test this serie of patch against your own
> apps as it could break things.
Already a fix for some swallow case.
--
Cedric BAIL
diff --git a/src/lib/edje_calc.c b/src/lib/edje_calc.c
index 005ca2b..131675f 100644
--- a/src/lib/edje_calc.c
+++ b/src/lib/edje_calc.c
@@ -136,13 +136,22 @@ _edje_part_description_apply(Edje *ed, Edje_Real_Part *ep, const char *d1, doubl
void
_edje_recalc(Edje *ed)
{
+ if (ed->postponed) return ;
+ evas_object_smart_changed(ed->obj);
+ ed->postponed = 1;
+}
+
+void
+_edje_recalc_do(Edje *ed)
+{
int i;
if (!ed->dirty) return;
if (ed->freeze)
{
ed->recalc = 1;
- if (!ed->calc_only) return;
+ if (!ed->calc_only &&
+ !ed->postponed) return;
}
for (i = 0; i < ed->table_parts_size; i++)
{
@@ -161,6 +170,7 @@ _edje_recalc(Edje *ed)
_edje_part_recalc(ed, ep, (~ep->calculated) & FLAG_XY);
}
ed->dirty = 0;
+ ed->postponed = 0;
if (!ed->calc_only) ed->recalc = 0;
}
diff --git a/src/lib/edje_private.h b/src/lib/edje_private.h
index 8d60b7e..edcd44d 100644
--- a/src/lib/edje_private.h
+++ b/src/lib/edje_private.h
@@ -681,6 +681,7 @@ struct _Edje
unsigned shortwalking_actions : 1;
unsigned shortblock_break : 1;
unsigned shortdelete_me : 1;
+ unsigned shortpostponed : 1;
};
struct _Edje_Real_Part
@@ -1007,6 +1008,7 @@ void _edje_part_pos_set(Edje *ed, Edje_Real_Part *ep, int mode, double pos);
Edje_Part_Description *_edje_part_description_find(Edje *ed, Edje_Real_Part *rp, const char *name, double val);
void _edje_part_description_apply(Edje *ed, Edje_Real_Part *ep, const char *d1, double v1, const char *d2, double v2);
void _edje_recalc(Edje *ed);
+void _edje_recalc_do(Edje *ed);
int _edje_part_dragable_calc(Edje *ed, Edje_Real_Part *ep, double *x, double *y);
void _edje_dragable_pos_set(Edje *ed, Edje_Real_Part *ep, double x, double y);
diff --git a/src/lib/edje_smart.c b/src/lib/edje_smart.c
index b4f027f..16b73f3 100644
--- a/src/lib/edje_smart.c
+++ b/src/lib/edje_smart.c
@@ -13,6 +13,7 @@ static void _edje_smart_hide(Evas_Object * obj);
static void _edje_smart_color_set(Evas_Object * obj, int r, int g, int b, int a);
static void _edje_smart_clip_set(Evas_Object * obj, Evas_Object * clip);
static void _edje_smart_clip_unset
Re: [E-devel] RFC: evas smart pre_render
On Mon, Aug 18, 2008 at 6:24 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 16, 2008 at 3:15 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>> Just to make it clear what I think about this: This kind of thing is
>> something that really needs to be done, one way or another. :)
>>
>> Some time back, I thought about having the edje recalc function called
>> by smart class render-pre/post funcs, and these funcs I wanted to be called
>> by the obj's internal render-pre/post ones as this would be useful for
>> creating
>> semi-custom, stateful, objs that rendered to image buffers (possibly native
>> surfaces). But I saw that there were problems with that due to the very kinds
>> of things you mention, the events system and possibly other things, as I
>> mentioned to Cedric once here.
>> You could have an additional smart class func, say a "calculate" one and
>> then do as you suggest.. but the main issue here is whether this kind of
>> smart
>> class specific approach is the "best" way to deal with this kind of general
>> issue.
>> I've mentioned two other possible ways to deal with this in a more
>> generic
>> manner - for example an ecore_evas based one akin to what's done with
>> sub-canvases
>> (which is useful for those), or a more 'evas only' one akin to what you have
>> here
>> but using user supplied callbacks. There are other possibilities.. evas could
>> expose an EVAS_RENDER_EVENT and have callbacks one can add for such, called
>> prior
>> to the internal evas-render loop... and other possibilities.
>
>> I don't know what might be best.. just that this is something needed but
>> that needs more thought, some experimenting, etc. Maybe raster, nathan,
>> hisham,
>> and others can give more feedback on this - maybe your proposal *is* the best
>> way to deal with this general issue, but it won't hurt to consider other
>> possible
>> ways if they have potentially wider applicability. :)
>
> Ok, here is a patch that improve the speed for evas part of Gustavo
> work. I did rename the callback to calculate. Regarding if it's the
> best way, that I don't know, but it's easy to implement on both side
> and fast.
>
> Between the edje patch is currently not correct as many getter expect
> the underlying object to be calculated. If you apply the attached
> patch (not really a smart patch) you will see that many user of edje
> expect it to be calculated at some point.
And here is the edje patch. It did fix E17 use of edje and I didn't
see any problem. But please test this serie of patch against your own
apps as it could break things.
--
Cedric BAIL
diff --git a/src/lib/edje_calc.c b/src/lib/edje_calc.c
index 005ca2b..131675f 100644
--- a/src/lib/edje_calc.c
+++ b/src/lib/edje_calc.c
@@ -136,13 +136,22 @@ _edje_part_description_apply(Edje *ed, Edje_Real_Part *ep, const char *d1, doubl
void
_edje_recalc(Edje *ed)
{
+ if (ed->postponed) return ;
+ evas_object_smart_changed(ed->obj);
+ ed->postponed = 1;
+}
+
+void
+_edje_recalc_do(Edje *ed)
+{
int i;
if (!ed->dirty) return;
if (ed->freeze)
{
ed->recalc = 1;
- if (!ed->calc_only) return;
+ if (!ed->calc_only &&
+ !ed->postponed) return;
}
for (i = 0; i < ed->table_parts_size; i++)
{
@@ -161,6 +170,7 @@ _edje_recalc(Edje *ed)
_edje_part_recalc(ed, ep, (~ep->calculated) & FLAG_XY);
}
ed->dirty = 0;
+ ed->postponed = 0;
if (!ed->calc_only) ed->recalc = 0;
}
diff --git a/src/lib/edje_private.h b/src/lib/edje_private.h
index 8d60b7e..edcd44d 100644
--- a/src/lib/edje_private.h
+++ b/src/lib/edje_private.h
@@ -681,6 +681,7 @@ struct _Edje
unsigned shortwalking_actions : 1;
unsigned shortblock_break : 1;
unsigned shortdelete_me : 1;
+ unsigned shortpostponed : 1;
};
struct _Edje_Real_Part
@@ -1007,6 +1008,7 @@ void _edje_part_pos_set(Edje *ed, Edje_Real_Part *ep, int mode, double pos);
Edje_Part_Description *_edje_part_description_find(Edje *ed, Edje_Real_Part *rp, const char *name, double val);
void _edje_part_description_apply(Edje *ed, Edje_Real_Part *ep, const char *d1, double v1, const char *d2, double v2);
void _edje_recalc(Edje *ed);
+void _edje_recalc_do(Edje *ed);
int _edje_part_dragable_calc(Edje *ed, Edje_Real_Part *ep, double *x, double *y);
void _edje_dragable_pos_set(Edje *ed, Edje_Real_Part *ep, double x, double y);
diff --git a/src/lib/edje_smart.c b/src/lib/edje_smart.c
index b4f027f..16b73f3 100644
--- a/src/lib/edje_smart.c
+++ b/src/lib/edje_smart.c
@@ -13,6 +13,7 @@ static void _edje_smart_hide(Evas_Object * obj);
static void _edje_smart_color_set(Evas_Object * obj, int r, int g, int b, int a);
static void _edje_smart_clip_set(Evas_Object * obj, Evas_Object * clip);
static void _edje_smart_clip_unset(Evas_Object * obj);
+static void _edje_smart_calculate(Evas_Object * obj);
static Evas_Smart *_edje_smart = NULL;
@@ -45,6 +46,7 @@ edje_object_add(Evas *evas)
_edje
Re: [E-devel] RFC: evas smart pre_render
Cedric BAIL wrote: > On Sat, Aug 16, 2008 at 3:15 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >> Just to make it clear what I think about this: This kind of thing is >> something that really needs to be done, one way or another. :) >> >> Some time back, I thought about having the edje recalc function called >> by smart class render-pre/post funcs, and these funcs I wanted to be called >> by the obj's internal render-pre/post ones as this would be useful for >> creating >> semi-custom, stateful, objs that rendered to image buffers (possibly native >> surfaces). But I saw that there were problems with that due to the very kinds >> of things you mention, the events system and possibly other things, as I >> mentioned to Cedric once here. >> You could have an additional smart class func, say a "calculate" one and >> then do as you suggest.. but the main issue here is whether this kind of >> smart >> class specific approach is the "best" way to deal with this kind of general >> issue. >> I've mentioned two other possible ways to deal with this in a more >> generic >> manner - for example an ecore_evas based one akin to what's done with >> sub-canvases >> (which is useful for those), or a more 'evas only' one akin to what you have >> here >> but using user supplied callbacks. There are other possibilities.. evas could >> expose an EVAS_RENDER_EVENT and have callbacks one can add for such, called >> prior >> to the internal evas-render loop... and other possibilities. >> > > >> I don't know what might be best.. just that this is something needed but >> that needs more thought, some experimenting, etc. Maybe raster, nathan, >> hisham, >> and others can give more feedback on this - maybe your proposal *is* the best >> way to deal with this general issue, but it won't hurt to consider other >> possible >> ways if they have potentially wider applicability. :) >> > > Ok, here is a patch that improve the speed for evas part of Gustavo > work. I did rename the callback to calculate. Regarding if it's the > best way, that I don't know, but it's easy to implement on both side > and fast. > > Between the edje patch is currently not correct as many getter expect > the underlying object to be calculated. If you apply the attached > patch (not really a smart patch) you will see that many user of edje > expect it to be calculated at some point. > > I still think this approach -- though a simple and seemingly straightforward solution to the issues you want to address with edje -- might be somewhat premature. In fact, I have the feeling that this kind of thing doesn't really belong in evas at all. It's not really about 'rendering' per se, but rather about synchronizing user-level calculations of various sorts with evas render calls.. and that's something that should really belong as exposed functionality of the ecore event loop with evas rendering. I also think it's way too smart-class specific for an issue that's really fairly generic in nature.. But, since I don't have a concrete alternative to provide instead right now, I'll let my arguments rest and leave it up to you guys to decide. :) Need cash? Click to get a cash advance. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mKes2WWGebBJuRv0ciRPVQtuQujaYRbFK1lHAnQ1IAYgDyX/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
On Sat, Aug 16, 2008 at 3:15 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> Just to make it clear what I think about this: This kind of thing is
> something that really needs to be done, one way or another. :)
>
> Some time back, I thought about having the edje recalc function called
> by smart class render-pre/post funcs, and these funcs I wanted to be called
> by the obj's internal render-pre/post ones as this would be useful for
> creating
> semi-custom, stateful, objs that rendered to image buffers (possibly native
> surfaces). But I saw that there were problems with that due to the very kinds
> of things you mention, the events system and possibly other things, as I
> mentioned to Cedric once here.
> You could have an additional smart class func, say a "calculate" one and
> then do as you suggest.. but the main issue here is whether this kind of smart
> class specific approach is the "best" way to deal with this kind of general
> issue.
> I've mentioned two other possible ways to deal with this in a more generic
> manner - for example an ecore_evas based one akin to what's done with
> sub-canvases
> (which is useful for those), or a more 'evas only' one akin to what you have
> here
> but using user supplied callbacks. There are other possibilities.. evas could
> expose an EVAS_RENDER_EVENT and have callbacks one can add for such, called
> prior
> to the internal evas-render loop... and other possibilities.
> I don't know what might be best.. just that this is something needed but
> that needs more thought, some experimenting, etc. Maybe raster, nathan,
> hisham,
> and others can give more feedback on this - maybe your proposal *is* the best
> way to deal with this general issue, but it won't hurt to consider other
> possible
> ways if they have potentially wider applicability. :)
Ok, here is a patch that improve the speed for evas part of Gustavo
work. I did rename the callback to calculate. Regarding if it's the
best way, that I don't know, but it's easy to implement on both side
and fast.
Between the edje patch is currently not correct as many getter expect
the underlying object to be calculated. If you apply the attached
patch (not really a smart patch) you will see that many user of edje
expect it to be calculated at some point.
--
Cedric BAIL
diff --git a/src/lib/Evas.h b/src/lib/Evas.h
index 1c45061..e001ac5 100644
--- a/src/lib/Evas.h
+++ b/src/lib/Evas.h
@@ -129,7 +129,7 @@ typedef enum _Evas_Aspect_Control
} Evas_Aspect_Control;
-#define EVAS_SMART_CLASS_VERSION 1 /** the version you have to put into the version field in the smart class struct */
+#define EVAS_SMART_CLASS_VERSION 2 /** the version you have to put into the version field in the smart class struct */
struct _Evas_Smart_Class /** a smart object class */
{
const char *name; /** the string name of the class */
@@ -145,6 +145,7 @@ struct _Evas_Smart_Class /** a smart object class */
void (*color_set) (Evas_Object *o, int r, int g, int b, int a); // FIXME: DELETE ME
void (*clip_set)(Evas_Object *o, Evas_Object *clip); // FIXME: DELETE ME
void (*clip_unset) (Evas_Object *o); // FIXME: DELETE ME
+ void (*calculate) (Evas_Object *o);
const void *data;
};
@@ -738,6 +739,7 @@ extern "C" {
EAPI void evas_object_smart_callback_add(Evas_Object *obj, const char *event, void (*func) (void *data, Evas_Object *obj, void *event_info), const void *data);
EAPI void *evas_object_smart_callback_del(Evas_Object *obj, const char *event, void (*func) (void *data, Evas_Object *obj, void *event_info));
EAPI void evas_object_smart_callback_call (Evas_Object *obj, const char *event, void *event_info);
+ EAPI void evas_object_smart_changed (Evas_Object *obj);
/* events */
EAPI void evas_event_freeze (Evas *e);
diff --git a/src/lib/canvas/evas_main.c b/src/lib/canvas/evas_main.c
index 27b3ce6..1a9b34c 100644
--- a/src/lib/canvas/evas_main.c
+++ b/src/lib/canvas/evas_main.c
@@ -70,6 +70,7 @@ evas_new(void)
evas_array_setup(&e->pending_objects, 16);
evas_array_setup(&e->obscuring_objects, 16);
evas_array_setup(&e->temporary_objects, 16);
+ evas_array_setup(&e->calculate_objects, 16);
return e;
}
diff --git a/src/lib/canvas/evas_object_smart.c b/src/lib/canvas/evas_object_smart.c
index aaffd3e..ec42e10 100644
--- a/src/lib/canvas/evas_object_smart.c
+++ b/src/lib/canvas/evas_object_smart.c
@@ -429,6 +429,21 @@ evas_object_smart_callback_call(Evas_Object *obj, const char *event, void *event
evas_object_smart_callbacks_clear(obj);
}
+/**
+ * Mark smart object as changed, dirty.
+ *
+ * This will inform the scene that it changed and needs to be redraw.
+ */
+EAPI void
+evas_object_smart_changed(Evas_Object *obj)
+{
+ MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
+ return;
+ MAGIC_CHECK_END();
+ evas_object_change(obj);
+ evas_render_object_
Re: [E-devel] RFC: evas smart pre_render
Just to make it clear what I think about this: This kind of thing is something that really needs to be done, one way or another. :) Some time back, I thought about having the edje recalc function called by smart class render-pre/post funcs, and these funcs I wanted to be called by the obj's internal render-pre/post ones as this would be useful for creating semi-custom, stateful, objs that rendered to image buffers (possibly native surfaces). But I saw that there were problems with that due to the very kinds of things you mention, the events system and possibly other things, as I mentioned to Cedric once here. You could have an additional smart class func, say a "calculate" one and then do as you suggest.. but the main issue here is whether this kind of smart class specific approach is the "best" way to deal with this kind of general issue. I've mentioned two other possible ways to deal with this in a more generic manner - for example an ecore_evas based one akin to what's done with sub-canvases (which is useful for those), or a more 'evas only' one akin to what you have here but using user supplied callbacks. There are other possibilities.. evas could expose an EVAS_RENDER_EVENT and have callbacks one can add for such, called prior to the internal evas-render loop... and other possibilities. I don't know what might be best.. just that this is something needed but that needs more thought, some experimenting, etc. Maybe raster, nathan, hisham, and others can give more feedback on this - maybe your proposal *is* the best way to deal with this general issue, but it won't hurt to consider other possible ways if they have potentially wider applicability. :) Save on Security Cameras. Click Now! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mYHqcMZpeeI6GMYSingyLEJrtZoIkkvR1SLez1NqqHdCcVW/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
I wrote: > Gustavo wrote: > >> ... >> Ok, if you suggest a better name, it can be used, but since it's used >> for pre-render, it is a good name, maybe before_render is an option. >> Too bad it conflicts with internal evas names, however it has nothing >> to do with the internal usage. >> >> As for restack, move, ... what more can we do from smart objects?! :-) >> As I said, they don't draw anything on their own, they just change >> other objects, that in turn will have their internals pre/post >> renders. >> >> As for the ecore-evas, it's exactly that pattern! We could try to >> achieve the same of my pre_render patch with ecore_idler_enterer(), >> but then evas would be dependent on ecore. to make it generic >> "Provide evas_pre_render_call()" you say, than call it from an >> ecore_idler_enterer (maybe the same as the one that calls >> evas_render()), but really, it's useless, as this is meant to make >> life easier and more robust, since these are linked (you want to run >> pre_render before you render), it makes no sense to have it separated. >> >> >> > You could, but frankly I don't see a need for it. This should be part of > a far more general evas wide render-pre/post functionality, wherein one can > add callbacks to be executed before/after the current internal evas-render > call, > it should definitely not be limited to smart-class related stuff. > Whether it should exposed in a manner exactly as with ecore-evas > sub-canvases > (and dependent on ecore_evas) or just similarly but the render-pre/post user > callbacks > called by the current evas_render api call (just before/after the actual > current > implementation), I'm not sure. > And note btw that if one chooses to go with the former method, it *doesn't* mean that evas would ebcome dependent on ecore, just that anything wanting to use such extra evas pre/post render calls would be dependent - and frankly most are. But that's only if one goes with exactly that kind of apporoach. Find precision scales that can weigh anything. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mPT3hVTzGbwfLA5vFU2anm5ZipYxLWa61xhLlMBXiqWu9aM/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
Gustavo wrote: > ... > Ok, if you suggest a better name, it can be used, but since it's used > for pre-render, it is a good name, maybe before_render is an option. > Too bad it conflicts with internal evas names, however it has nothing > to do with the internal usage. > > As for restack, move, ... what more can we do from smart objects?! :-) > As I said, they don't draw anything on their own, they just change > other objects, that in turn will have their internals pre/post > renders. > > As for the ecore-evas, it's exactly that pattern! We could try to > achieve the same of my pre_render patch with ecore_idler_enterer(), > but then evas would be dependent on ecore. to make it generic > "Provide evas_pre_render_call()" you say, than call it from an > ecore_idler_enterer (maybe the same as the one that calls > evas_render()), but really, it's useless, as this is meant to make > life easier and more robust, since these are linked (you want to run > pre_render before you render), it makes no sense to have it separated. > > You could, but frankly I don't see a need for it. This should be part of a far more general evas wide render-pre/post functionality, wherein one can add callbacks to be executed before/after the current internal evas-render call, it should definitely not be limited to smart-class related stuff. Whether it should exposed in a manner exactly as with ecore-evas sub-canvases (and dependent on ecore_evas) or just similarly but the render-pre/post user callbacks called by the current evas_render api call (just before/after the actual current implementation), I'm not sure. Explore all of Europe's beauty! Click now for great vacation packages! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nKHMERZsINzgM1HdTXB7d2BQMQZxJlWRSblJ8iPFNp4YB0A/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
Gustavo wrote: > > WHY SMART OBJECTS NEEDS TO BE DIFFERENT: > > Evas is not an immediate render library, instead it will do all the > calcs and render at the "render phase". Evas has a number of > pre-defined objects, like Rectangle, Text and more, but it also have > what we call "Smart Objects", these do not draw anything at all, it > just call user functions that can in turn manipulate these pre-defined > objects. > > Why Smart Objects can't use regular object's pre_render/post_render? > The way Evas is implemented, existing pre_render and post_render > cannot change the scene, that is, objects cannot move, restack, show > or disappear, no new objects can be created and much more limits, > otherwise the render phase could be never-ending. Since Smart Objects > do not draw by themselves, the only way they could draw is by means of > changing other objects, thus making them unable to join the existing > pre_render/post_render usage. That's why Smart Object pre-renders are > called before doing any real work painting work. > > One comment I should add to this here: Even though smart classes don't currently have a 'render' func, they could and if so would be called from their internal render function. This func isn't called at all right now, but it should - whether or not smart classes have such a user defined func which would be called by their internal render func. What the internal render func of smart objs should be doing (at least) is calling the render funcs of all its active member objs. They don't since it's a left-over legacy error from the prior 'wild' implementation od smart objs -- which was largely corrected subsequently by raster but still has this left-over bit hanging. This is needed, apart from logical and other considerations, if there's ever any real hope to get smart objs to render (their children) to an internal buffer, which could be needed/useful for many kinds of things. Click to see huge collection of discounted designer watches. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mdA3cNOEx4Vykv6rSw8hrkFEup72rJm5qJc0BNLdeoDHmiw/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
On Fri, Aug 15, 2008 at 3:56 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Before and after evas_render that is. Again, like ecore_evas does for > subcanvases.. maybe even keep those calls internal to evas and just expose > a means to add user render-pre/post callbacks which are then called > internally by evas_render_pre/post funcs before/after evas_render. > But smart class funcs for render_pre/post, called in the internal obj's > render_pre/post funcs, are *very* useful for creating custom renderable > objs, > even if it just means drawing to some image objs associated with the smart. writing to another image is great example, but fortunately covered by this implementation, as you can do it before without any problems. Actually, it must be done before entering current render loop, otherwise when you mark the image as dirty it will be late and it will not be in the correct update lists. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: evas smart pre_render
On Fri, Aug 15, 2008 at 3:19 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Gustavo wrote: >> >> On Thu, Aug 14, 2008 at 9:36 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: >> >>> >>> Gustavo wrote: >>> Attached is a patch (txt so gmail/firefox don't think it's an octet-stream and is removed by mailman) to add pre_render() to Evas_Smart_Class. This patch applies on e17/libs and hacks edje and emotion so we can test. CAUTION: if you compile and install Evas with this patch, it will change the EVAS_SMART_CLASS_VERSION, making ALL existing binaries incompatible, so if you do this and your E or other Evas-dependent application crashes, it will not restart until you reverse the patch, compile and install the old (non-patched) Evas. USE CASE: Most users of smart objects end with nasty freeze/thaw to avoid heavy computations, this can be seen in many places, including Edje. It would be lot better if we could avoid this if we know when we need to compute, recalc, reconfigure, ... things. And we know: before drawing! So why not make this automatic? IMPLEMENTATION: I don't know this part of Evas internals that much, but I hacked it as a walk of all objects (layers, then its objects) and checking if object changed and if it is a smart and if it has the new pre_render callback. In this case, call this function. This is done BEFORE any other stuff, before obscure, dirty, etc... calcs, so it will not impact existing evas_render code at all. >>> >>>Well, you really need both pre-render and post-render smart class >>> funcs. >>> This is in case you want to track state (say in the smart data) via >>> cur/prev >>> states. >>>You don't need to walk a new list - all evas objects have internal >>> render-pre and render-post fucntions which are called before and after >>> the actual obj rendering calls (during evas render). Smart objects have >>> these too, and are called.. it's just they don't do much right now. >>> >>>All you have to do is go to the "evas_object_smart.c" file (in the >>> src/lib/ >>> canvas dir), and at the very bottom of that file there are these two >>> functions: >>> >>> static void >>> evas_object_smart_render_pre(Evas_Object *obj) >>> >>> static void >>> evas_object_smart_render_post(Evas_Object *obj) >>> >>>In those functions, simply add calls to the corresponding smart obj's >>> new class functions. :) >>> >>> >>> In order to mark smart objects dirty without doing any operation, I added evas_object_smart_changed(), that will call evas_object_changed(). Maybe something better could be done? Edje was changed and _edje_recalc() just calls evas_object_smart_changed(), while _edje_recalc_do() will do the actual work. THIS IS A TEMPORARY HACK. Emotion has no callback, so pre_render = NULL, just to make it compile. NEXT STEPS: If this proves to be correct, we need to patch all uses of Evas_Smart_Class. This is about 50 on current cvs e17. >> >> Ok, from Jose's mail I can see that even the experienced lack some >> details of the problem, so I'll add more to my original mail: >> >> WHY SMART OBJECTS NEEDS TO BE DIFFERENT: >> >> Evas is not an immediate render library, instead it will do all the >> calcs and render at the "render phase". Evas has a number of >> pre-defined objects, like Rectangle, Text and more, but it also have >> what we call "Smart Objects", these do not draw anything at all, it >> just call user functions that can in turn manipulate these pre-defined >> objects. >> >> Why Smart Objects can't use regular object's pre_render/post_render? >> The way Evas is implemented, existing pre_render and post_render >> cannot change the scene, that is, objects cannot move, restack, show >> or disappear, no new objects can be created and much more limits, >> otherwise the render phase could be never-ending. Since Smart Objects >> do not draw by themselves, the only way they could draw is by means of >> changing other objects, thus making them unable to join the existing >> pre_render/post_render usage. That's why Smart Object pre-renders are >> called before doing any real work painting work. >> >> > >If that's what you want, to restack, move, etc.. Then the way you're > doing > it is extremely bad design. It should instaed be done by adding > evas-render-pre/post > api funcs which would be called before evas render, similar to what > ecore_evas > does with sub-canvases. What you want, via smart objs, is not only limited > in > scope but also 'breaks' the existing semantics of such smart callbacks to > some > degree. >It *is* useful to have smart class callbaks for smart objs internal > render-pre/ > post functions. But you'll have to think a bit outside the needs you're > looking > at right now (edje recalc) to see it. :) Ok, if you suggest a
Re: [E-devel] RFC: evas smart pre_render
I wrote: > Gustavo wrote: > >> On Thu, Aug 14, 2008 at 9:36 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: >> >> >>> Gustavo wrote: >>> >>> Attached is a patch (txt so gmail/firefox don't think it's an octet-stream and is removed by mailman) to add pre_render() to Evas_Smart_Class. This patch applies on e17/libs and hacks edje and emotion so we can test. CAUTION: if you compile and install Evas with this patch, it will change the EVAS_SMART_CLASS_VERSION, making ALL existing binaries incompatible, so if you do this and your E or other Evas-dependent application crashes, it will not restart until you reverse the patch, compile and install the old (non-patched) Evas. USE CASE: Most users of smart objects end with nasty freeze/thaw to avoid heavy computations, this can be seen in many places, including Edje. It would be lot better if we could avoid this if we know when we need to compute, recalc, reconfigure, ... things. And we know: before drawing! So why not make this automatic? IMPLEMENTATION: I don't know this part of Evas internals that much, but I hacked it as a walk of all objects (layers, then its objects) and checking if object changed and if it is a smart and if it has the new pre_render callback. In this case, call this function. This is done BEFORE any other stuff, before obscure, dirty, etc... calcs, so it will not impact existing evas_render code at all. >>> Well, you really need both pre-render and post-render smart class funcs. >>> This is in case you want to track state (say in the smart data) via cur/prev >>> states. >>> You don't need to walk a new list - all evas objects have internal >>> render-pre and render-post fucntions which are called before and after >>> the actual obj rendering calls (during evas render). Smart objects have >>> these too, and are called.. it's just they don't do much right now. >>> >>> All you have to do is go to the "evas_object_smart.c" file (in the >>> src/lib/ >>> canvas dir), and at the very bottom of that file there are these two >>> functions: >>> >>> static void >>> evas_object_smart_render_pre(Evas_Object *obj) >>> >>> static void >>> evas_object_smart_render_post(Evas_Object *obj) >>> >>> In those functions, simply add calls to the corresponding smart obj's >>> new class functions. :) >>> >>> >>> >>> In order to mark smart objects dirty without doing any operation, I added evas_object_smart_changed(), that will call evas_object_changed(). Maybe something better could be done? Edje was changed and _edje_recalc() just calls evas_object_smart_changed(), while _edje_recalc_do() will do the actual work. THIS IS A TEMPORARY HACK. Emotion has no callback, so pre_render = NULL, just to make it compile. NEXT STEPS: If this proves to be correct, we need to patch all uses of Evas_Smart_Class. This is about 50 on current cvs e17. >> Ok, from Jose's mail I can see that even the experienced lack some >> details of the problem, so I'll add more to my original mail: >> >> WHY SMART OBJECTS NEEDS TO BE DIFFERENT: >> >> Evas is not an immediate render library, instead it will do all the >> calcs and render at the "render phase". Evas has a number of >> pre-defined objects, like Rectangle, Text and more, but it also have >> what we call "Smart Objects", these do not draw anything at all, it >> just call user functions that can in turn manipulate these pre-defined >> objects. >> >> Why Smart Objects can't use regular object's pre_render/post_render? >> The way Evas is implemented, existing pre_render and post_render >> cannot change the scene, that is, objects cannot move, restack, show >> or disappear, no new objects can be created and much more limits, >> otherwise the render phase could be never-ending. Since Smart Objects >> do not draw by themselves, the only way they could draw is by means of >> changing other objects, thus making them unable to join the existing >> pre_render/post_render usage. That's why Smart Object pre-renders are >> called before doing any real work painting work. >> >> >> > > If that's what you want, to restack, move, etc.. Then the way you're > doing > it is extremely bad design. It should instaed be done by adding > evas-render-pre/post > api funcs which would be called before evas render, similar to what ecore_evas > Before and after evas_render that is. Again, like ecore_evas does for subcanvases.. maybe even keep those calls internal to evas and just expose a means to add user render-pre/post callbacks which are then called internally by evas_render_pre/post funcs before/after evas_render. But smart class funcs for render_pre/post, called in the internal obj's render_pre/post funcs, are *very*
Re: [E-devel] RFC: evas smart pre_render
Gustavo wrote: > On Thu, Aug 14, 2008 at 9:36 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >> Gustavo wrote: >> >>> Attached is a patch (txt so gmail/firefox don't think it's an >>> octet-stream and is removed by mailman) to add pre_render() to >>> Evas_Smart_Class. This patch applies on e17/libs and hacks edje and >>> emotion so we can test. >>> >>> CAUTION: if you compile and install Evas with this patch, it will >>> change the EVAS_SMART_CLASS_VERSION, making ALL existing binaries >>> incompatible, so if you do this and your E or other Evas-dependent >>> application crashes, it will not restart until you reverse the patch, >>> compile and install the old (non-patched) Evas. >>> >>> USE CASE: >>> >>> Most users of smart objects end with nasty freeze/thaw to avoid heavy >>> computations, this can be seen in many places, including Edje. It >>> would be lot better if we could avoid this if we know when we need to >>> compute, recalc, reconfigure, ... things. And we know: before drawing! >>> So why not make this automatic? >>> >>> IMPLEMENTATION: >>> >>> I don't know this part of Evas internals that much, but I hacked it as >>> a walk of all objects (layers, then its objects) and checking if >>> object changed and if it is a smart and if it has the new pre_render >>> callback. In this case, call this function. This is done BEFORE any >>> other stuff, before obscure, dirty, etc... calcs, so it will not >>> impact existing evas_render code at all. >>> >>> >> Well, you really need both pre-render and post-render smart class funcs. >> This is in case you want to track state (say in the smart data) via cur/prev >> states. >> You don't need to walk a new list - all evas objects have internal >> render-pre and render-post fucntions which are called before and after >> the actual obj rendering calls (during evas render). Smart objects have >> these too, and are called.. it's just they don't do much right now. >> >> All you have to do is go to the "evas_object_smart.c" file (in the >> src/lib/ >> canvas dir), and at the very bottom of that file there are these two >> functions: >> >> static void >> evas_object_smart_render_pre(Evas_Object *obj) >> >> static void >> evas_object_smart_render_post(Evas_Object *obj) >> >> In those functions, simply add calls to the corresponding smart obj's >> new class functions. :) >> >> >> >>>In order to mark smart objects dirty without doing any operation, >>> I added evas_object_smart_changed(), that will call >>> evas_object_changed(). Maybe something better could be done? >>> >>> Edje was changed and _edje_recalc() just calls >>> evas_object_smart_changed(), while _edje_recalc_do() will do the >>> actual work. THIS IS A TEMPORARY HACK. >>> >>> Emotion has no callback, so pre_render = NULL, just to make it compile. >>> >>> >>> >>> NEXT STEPS: >>> >>> If this proves to be correct, we need to patch all uses of >>> Evas_Smart_Class. This is about 50 on current cvs e17. >>> > > Ok, from Jose's mail I can see that even the experienced lack some > details of the problem, so I'll add more to my original mail: > > WHY SMART OBJECTS NEEDS TO BE DIFFERENT: > > Evas is not an immediate render library, instead it will do all the > calcs and render at the "render phase". Evas has a number of > pre-defined objects, like Rectangle, Text and more, but it also have > what we call "Smart Objects", these do not draw anything at all, it > just call user functions that can in turn manipulate these pre-defined > objects. > > Why Smart Objects can't use regular object's pre_render/post_render? > The way Evas is implemented, existing pre_render and post_render > cannot change the scene, that is, objects cannot move, restack, show > or disappear, no new objects can be created and much more limits, > otherwise the render phase could be never-ending. Since Smart Objects > do not draw by themselves, the only way they could draw is by means of > changing other objects, thus making them unable to join the existing > pre_render/post_render usage. That's why Smart Object pre-renders are > called before doing any real work painting work. > > If that's what you want, to restack, move, etc.. Then the way you're doing it is extremely bad design. It should instaed be done by adding evas-render-pre/post api funcs which would be called before evas render, similar to what ecore_evas does with sub-canvases. What you want, via smart objs, is not only limited in scope but also 'breaks' the existing semantics of such smart callbacks to some degree. It *is* useful to have smart class callbaks for smart objs internal render-pre/ post functions. But you'll have to think a bit outside the needs you're looking at right now (edje recalc) to see it. :) > Why not add post_render? Because there is no use case for those, and > adding just for completeness sake would add yet another O(n) walk over > the objects. > > Give me some examples of Smart Object pre_render u
Re: [E-devel] RFC: evas smart pre_render
On Thu, Aug 14, 2008 at 9:36 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Gustavo wrote: >> >> Attached is a patch (txt so gmail/firefox don't think it's an >> octet-stream and is removed by mailman) to add pre_render() to >> Evas_Smart_Class. This patch applies on e17/libs and hacks edje and >> emotion so we can test. >> >> CAUTION: if you compile and install Evas with this patch, it will >> change the EVAS_SMART_CLASS_VERSION, making ALL existing binaries >> incompatible, so if you do this and your E or other Evas-dependent >> application crashes, it will not restart until you reverse the patch, >> compile and install the old (non-patched) Evas. >> >> USE CASE: >> >> Most users of smart objects end with nasty freeze/thaw to avoid heavy >> computations, this can be seen in many places, including Edje. It >> would be lot better if we could avoid this if we know when we need to >> compute, recalc, reconfigure, ... things. And we know: before drawing! >> So why not make this automatic? >> >> IMPLEMENTATION: >> >> I don't know this part of Evas internals that much, but I hacked it as >> a walk of all objects (layers, then its objects) and checking if >> object changed and if it is a smart and if it has the new pre_render >> callback. In this case, call this function. This is done BEFORE any >> other stuff, before obscure, dirty, etc... calcs, so it will not >> impact existing evas_render code at all. >> > > Well, you really need both pre-render and post-render smart class funcs. > This is in case you want to track state (say in the smart data) via cur/prev > states. > You don't need to walk a new list - all evas objects have internal > render-pre and render-post fucntions which are called before and after > the actual obj rendering calls (during evas render). Smart objects have > these too, and are called.. it's just they don't do much right now. > > All you have to do is go to the "evas_object_smart.c" file (in the > src/lib/ > canvas dir), and at the very bottom of that file there are these two > functions: > > static void > evas_object_smart_render_pre(Evas_Object *obj) > > static void > evas_object_smart_render_post(Evas_Object *obj) > > In those functions, simply add calls to the corresponding smart obj's > new class functions. :) > > >>In order to mark smart objects dirty without doing any operation, >> I added evas_object_smart_changed(), that will call >> evas_object_changed(). Maybe something better could be done? >> >> Edje was changed and _edje_recalc() just calls >> evas_object_smart_changed(), while _edje_recalc_do() will do the >> actual work. THIS IS A TEMPORARY HACK. >> >> Emotion has no callback, so pre_render = NULL, just to make it compile. >> >> >> >> NEXT STEPS: >> >> If this proves to be correct, we need to patch all uses of >> Evas_Smart_Class. This is about 50 on current cvs e17. Ok, from Jose's mail I can see that even the experienced lack some details of the problem, so I'll add more to my original mail: WHY SMART OBJECTS NEEDS TO BE DIFFERENT: Evas is not an immediate render library, instead it will do all the calcs and render at the "render phase". Evas has a number of pre-defined objects, like Rectangle, Text and more, but it also have what we call "Smart Objects", these do not draw anything at all, it just call user functions that can in turn manipulate these pre-defined objects. Why Smart Objects can't use regular object's pre_render/post_render? The way Evas is implemented, existing pre_render and post_render cannot change the scene, that is, objects cannot move, restack, show or disappear, no new objects can be created and much more limits, otherwise the render phase could be never-ending. Since Smart Objects do not draw by themselves, the only way they could draw is by means of changing other objects, thus making them unable to join the existing pre_render/post_render usage. That's why Smart Object pre-renders are called before doing any real work painting work. Why not add post_render? Because there is no use case for those, and adding just for completeness sake would add yet another O(n) walk over the objects. Give me some examples of Smart Object pre_render usage: You have a layout (ie: VBox, HBox, Grid) and you want to add multiple items there, but you don't want to recalculate position of every object as you add then, because depending on the layout algorithm you can end with O(n^2) or worse easily. What you usually do? You add a counter (frozen count) that if > 0 you avoid any calcs, then after you're done you make it 0 and recalc as required. But doing this everywhere is error prone and boring, still you might have 2 batch of these between scenes, doing the first recalc without need. To solve this, we could postpone recalcs until we actually draw the scene, we would avoid the counter and would avoid extra calcs. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECT
Re: [E-devel] RFC: evas smart pre_render
Gustavo wrote: > Attached is a patch (txt so gmail/firefox don't think it's an > octet-stream and is removed by mailman) to add pre_render() to > Evas_Smart_Class. This patch applies on e17/libs and hacks edje and > emotion so we can test. > > CAUTION: if you compile and install Evas with this patch, it will > change the EVAS_SMART_CLASS_VERSION, making ALL existing binaries > incompatible, so if you do this and your E or other Evas-dependent > application crashes, it will not restart until you reverse the patch, > compile and install the old (non-patched) Evas. > > USE CASE: > > Most users of smart objects end with nasty freeze/thaw to avoid heavy > computations, this can be seen in many places, including Edje. It > would be lot better if we could avoid this if we know when we need to > compute, recalc, reconfigure, ... things. And we know: before drawing! > So why not make this automatic? > > IMPLEMENTATION: > > I don't know this part of Evas internals that much, but I hacked it as > a walk of all objects (layers, then its objects) and checking if > object changed and if it is a smart and if it has the new pre_render > callback. In this case, call this function. This is done BEFORE any > other stuff, before obscure, dirty, etc... calcs, so it will not > impact existing evas_render code at all. > Well, you really need both pre-render and post-render smart class funcs. This is in case you want to track state (say in the smart data) via cur/prev states. You don't need to walk a new list - all evas objects have internal render-pre and render-post fucntions which are called before and after the actual obj rendering calls (during evas render). Smart objects have these too, and are called.. it's just they don't do much right now. All you have to do is go to the "evas_object_smart.c" file (in the src/lib/ canvas dir), and at the very bottom of that file there are these two functions: static void evas_object_smart_render_pre(Evas_Object *obj) static void evas_object_smart_render_post(Evas_Object *obj) In those functions, simply add calls to the corresponding smart obj's new class functions. :) > In order to mark smart objects dirty without doing any operation, > I added evas_object_smart_changed(), that will call > evas_object_changed(). Maybe something better could be done? > > Edje was changed and _edje_recalc() just calls > evas_object_smart_changed(), while _edje_recalc_do() will do the > actual work. THIS IS A TEMPORARY HACK. > > Emotion has no callback, so pre_render = NULL, just to make it compile. > > > > NEXT STEPS: > > If this proves to be correct, we need to patch all uses of > Evas_Smart_Class. This is about 50 on current cvs e17. > > Save on Emergency Alert Systems. Click here. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mXtZ5hGjGOwlcDdAwMiDJvQslzo7CyCPi8FlBgEWoO6P0b6/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] RFC: evas smart pre_render
Attached is a patch (txt so gmail/firefox don't think it's an
octet-stream and is removed by mailman) to add pre_render() to
Evas_Smart_Class. This patch applies on e17/libs and hacks edje and
emotion so we can test.
CAUTION: if you compile and install Evas with this patch, it will
change the EVAS_SMART_CLASS_VERSION, making ALL existing binaries
incompatible, so if you do this and your E or other Evas-dependent
application crashes, it will not restart until you reverse the patch,
compile and install the old (non-patched) Evas.
USE CASE:
Most users of smart objects end with nasty freeze/thaw to avoid heavy
computations, this can be seen in many places, including Edje. It
would be lot better if we could avoid this if we know when we need to
compute, recalc, reconfigure, ... things. And we know: before drawing!
So why not make this automatic?
IMPLEMENTATION:
I don't know this part of Evas internals that much, but I hacked it as
a walk of all objects (layers, then its objects) and checking if
object changed and if it is a smart and if it has the new pre_render
callback. In this case, call this function. This is done BEFORE any
other stuff, before obscure, dirty, etc... calcs, so it will not
impact existing evas_render code at all.
In order to mark smart objects dirty without doing any operation,
I added evas_object_smart_changed(), that will call
evas_object_changed(). Maybe something better could be done?
Edje was changed and _edje_recalc() just calls
evas_object_smart_changed(), while _edje_recalc_do() will do the
actual work. THIS IS A TEMPORARY HACK.
Emotion has no callback, so pre_render = NULL, just to make it compile.
NEXT STEPS:
If this proves to be correct, we need to patch all uses of
Evas_Smart_Class. This is about 50 on current cvs e17.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Index: edje/src/lib/edje_calc.c
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_calc.c,v
retrieving revision 1.127
diff -u -p -r1.127 edje_calc.c
--- edje/src/lib/edje_calc.c7 Jun 2008 10:06:13 - 1.127
+++ edje/src/lib/edje_calc.c14 Aug 2008 22:55:39 -
@@ -136,7 +136,16 @@ _edje_part_description_apply(Edje *ed, E
void
_edje_recalc(Edje *ed)
{
+ puts("_edje_recalc postponed");
+ evas_object_smart_changed(ed->obj);
+}
+
+void
+_edje_recalc_do(Edje *ed)
+{
int i;
+
+ puts(">> DO EDJE RECALC!");
if (!ed->dirty) return;
if (ed->freeze)
Index: edje/src/lib/edje_private.h
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_private.h,v
retrieving revision 1.154
diff -u -p -r1.154 edje_private.h
--- edje/src/lib/edje_private.h 14 Aug 2008 18:21:27 - 1.154
+++ edje/src/lib/edje_private.h 14 Aug 2008 22:55:39 -
@@ -1007,6 +1007,7 @@ void _edje_part_pos_set(Edje *ed, Edje_
Edje_Part_Description *_edje_part_description_find(Edje *ed, Edje_Real_Part
*rp, const char *name, double val);
void _edje_part_description_apply(Edje *ed, Edje_Real_Part *ep, const char
*d1, double v1, const char *d2, double v2);
void _edje_recalc(Edje *ed);
+void _edje_recalc_do(Edje *ed);
int _edje_part_dragable_calc(Edje *ed, Edje_Real_Part *ep, double *x, double
*y);
void _edje_dragable_pos_set(Edje *ed, Edje_Real_Part *ep, double x, double y);
Index: edje/src/lib/edje_smart.c
===
RCS file: /cvs/e/e17/libs/edje/src/lib/edje_smart.c,v
retrieving revision 1.35
diff -u -p -r1.35 edje_smart.c
--- edje/src/lib/edje_smart.c 7 Jun 2008 10:06:13 - 1.35
+++ edje/src/lib/edje_smart.c 14 Aug 2008 22:55:39 -
@@ -13,6 +13,7 @@ static void _edje_smart_hide(Evas_Object
static void _edje_smart_color_set(Evas_Object * obj, int r, int g, int b, int
a);
static void _edje_smart_clip_set(Evas_Object * obj, Evas_Object * clip);
static void _edje_smart_clip_unset(Evas_Object * obj);
+static void _edje_smart_pre_render(Evas_Object * obj);
static Evas_Smart *_edje_smart = NULL;
@@ -45,6 +46,7 @@ edje_object_add(Evas *evas)
_edje_smart_color_set,
_edje_smart_clip_set,
_edje_smart_clip_unset,
+ _edje_smart_pre_render,
NULL
};
_edje_smart = evas_smart_class_new(&sc);
@@ -236,4 +238,15 @@ _edje_smart_clip_unset(Evas_Object * obj
if (!evas_object_clip_get(obj)) return;
evas_object_clip_unset(ed->clipper);
// _edje_emit(ed, "clip_unset", NULL);
+}
+
+static void
+_edje_smart_pre_render(Evas_Object *obj)
+{
+ Edje *ed;
+
+ ed = evas_object_smart_data_get(obj);
+ if (!ed) return;
+ puts("_edje_smart_pre_render!");
+ _edje_recalc_do(ed);
}
Index: emotion/src/lib/emotion_smart.c
=
