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* useful for creating custom renderable objs,
even if it just means drawing to some image objs associated with the smart.
> 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 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.
>>
>>
>>
>>
>
>
____________________________________________________________
Click to get information on owning your own franchise. Great products. Low
entry cost.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oKL76oFV5rheYOGUfQ9UeqdifvSx72SJQ6smRxYEuLrauBG/
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
