On Wed, 17 Aug 2005 01:00:38 -0400 Jose O Gonzalez <[EMAIL PROTECTED]> babbled:
OK man ... I am goign to TRY answer your mails... one by one... :) > 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. agreed. api-wise its clean, internally its nasty. > 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. i'd agree somewhat to that. mind you my focus is on getting e17 the wm out and only on whats necessary to get that done. i'd dearly love it if i could spend the next 5 years makign evas internals perfect... but i know i am putting them off myself. > 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. indeed. you have very much got the idea of it all :) > 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..). i actually think there are 2 thngs we can do. 1. move al sub objects of smart objects into the smart object istelf as a list within the object and propagate changed flags to parent objects so we know if we have to walk a smart bojects child list to find changes or not. this will b a big win and no major api changes at all are needed. it woudl be very clean and neat and solve stackign and other issues beautifully. 2. you want smart objects that can define their own rendering directly. imho this is best done in a sway that an app can literally extend evas with new object types. right now its not so well defined and easy to just add a new object type easily. i know how to do it. its' not that bad, but its is a bit of blakc magic. this would be closer to what you want i think. this woudl also be a win for certain kinds of "object" people may want. > 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. yup - as above. i think this is best done as a way of making new object primitives. smart objects are just ways fo grouping existing objects and code defining the logic of that grouping - how they group and behave as such. :) > 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. i think it may be best to allow one object type to access the renderer of another easily. right now it is possible - but not that pretty. it coudl be made easy and thus new object types coudl build off existing object types rendering code. > Some parts of the canvas code currently "tend" towards > adopting this kind of semantics, but it's not coherently applied > throughout. yeah - i think theres 2 schools here and they both have their purposes. we need and want both. we can fix 1 without any api extensions or changes. and that will cover a huge host of issues for us. :) > 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. yup. here too. if we moved child objects of a smart into the smart and out of the main toplevel objetc list we'd have a big win for all of this. :) > 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.. :) not as wild as your e-mails! :) so summary: yes. i agree. i think the solution is to 1. put off object extension stuff and defining rendering calls till later and focus on fixing smart objects, moving smart object children ONLY into the smart objects etc. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- 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
