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 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. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
