From: Jose G. <jos...@ju...> - 2008-08-15 18:54:48
|
I wrote: > Gustavo wrote: > >> On Thu, Aug 14, 2008 at 9:36 PM, Jose Gonzalez <jos...@ju...> 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/ |