There are some aspects of evas' internals, particularly in relation to "smart" objects, that I'd like to expound upon here - especially since it relates to some issues I've met while recently trying to finish off some things :)
In evas, the addition of "clip" objects (and possibly other kinds of 'modifier' objects, eg. filter objects, texture objects, ...), and the addition of "smart" objects, has made the internal logic of the canvas difficult to follow and control - there's too much ambiguity as to who controls what, responds to what, which functions are to be called when.., etc. In order to have an efficient rendering path, and to maintain flexibility with partly external objects like smart objects (and with modifier types of objects like clip objects), the canvas internals need to be somewhat redone. The main source of problems stems from the fact that each layer maintains a list of all objects 'in' the layer. Basically, when rendering the evas, one does something like: for each layer, one steps thru its list of objects in a 'pre-render' stage, and while doing this one builds another list of objects which is then stepped thru in a 'render' stage, and lastly one steps thru a 'post-render' stage. Objects that are 'modifier' kinds of objects, like clip objects, and objects which currently are not themselves directly 'renderable', like smart objects, have to be excluded from some of these steps - in the case of smart objects it's because currently there's nothing for them to "do" to themselves that wouldn't also involve doing things to their members.. and that's going to (possibly) get done when stepping thru the layers as we reach those member objects.. The point of the 'pre-render/post-render' stages is mainly twofold: to allow for objects to determine what parts of their state has changed since the 'last' rendering, and to allow for objects to defer expensive computations and such, until we are about to actually render the canvas.. Thus, if possible, state changes are only 'realized' internally when needed, and only those changes rel to the last time rendering occurred. In particular, this allows one to determine things like which areas need to be rendered again, rather than having to render the entire canvas each time. Currently, there's no way to have smart objects pre-render/render/post-render themselves unless we impose restrictions on the stacking order of their member objects, and/or modify the layers' object lists, and alter the rendering path somewhat. A partial step forward would be to provide smart objects with the ability to specify 'pre-render' and 'post-render' kinds of functions (eg. a 'text-formatting/layout' lib based on some smart class would have the pre-render function do something like: if object's layout state has changed, recalculate things accordingly..). Increasing the requirements on the parent/child relationship between smart objects and their members would allow for further refinements of this, and even for an (external) 'render' callback to be set on smart objects. They still cannot access rendering internals, and any internal rendering they might do on their own (by altering image data via their own resources and such), they could just as well do in the pre-render callback. What it would allow is for a generic means to handle the situation - one which would be useful to have for other types which *could* access engine internals (like evas-objects). It would allow one to define the internal default behavior of the render function for smart objects, ie. to render all their member objects (in their stacking order). It also gives a coherent semantics to the behavior of things like 'nested' smart objects, since one'd have a tree structure formed out of the parent/child relationship. Some parts of the canvas code currently "tend" towards adopting this kind of semantics, but it's not coherently applied throughout. Currently, a smart object's members can't quite make up their minds wether they belong to the smart object, or to the layer.. Right now they belong to both, in ways which vary in semantics from function to function - not altogether clearly or consistently. Let me try and give some idea of what I mean by this. Suppose you asked for the 'topmost' object in an evas, ie. called the api function "evas_object_top_get(evas)". Will you get the object which is at the top of the stacking order? eg, will you get an object that you set via "evas_object_raise(obj)" where you know that the obj belongs to the topmost layer.. Well, it depends... if the obj is a member of a smart object then you won't. What you will get is the highest object which has no 'parent', ie. is not a member of some smart object. Similar behavior obtains with other stacking-order 'get' api functions such as "evas_object_above_get". However, the related stacking-order 'set' functions like "evas_object_raise", "evas_object_stack_above", and some of the 'get' functions like "evas_object_top_at_xy_get", do not care wether an object has a 'parent' or is a 'parent', at least not as far as stacking order is concerned.. Similar variations exist for "event" related api functions when dealing with the 'parent/child' relation that smart objects have introduced. This is clearly not a well defined state of affairs -- either smart objects "own" their children, and/or the layer does. If both (so that smart objects are like disconnected blobs), then what is a clear, consistent semantics for stacking order, event handling, and associated api functions? Smart objects are just too wild.. :) Jose. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel