On Sun, 21 Aug 2005 12:29:16 +0200 Simon TRENY <[EMAIL PROTECTED]> babbled:
> Hi Jose, i think the real solution is to move child objects of a smart object out of the regualr object list and into the smart objects' inernal list and do stacking within an object only etc. thus rendering is now a recursive walk down smart objects to and stacking is onyl WITHIN a smart object etc. this will sovle a lot of these problems much mroe cleanly imho :) > I don't know very well the evas internals but here is what I think. > In my opinion, smart objects are only a way to combinate several > primitive evas objects and make them a coherent object. So I don't think > you'll need to add the prerender/postrender things in a smart object, > prerender and postrender are done in each member objects. If you want to > have more control on how your object is rendered, I think you have to > make a new primitive evas object and to add it directly in the evas API. > > The main problem with smart objects currently is imho, the stacking > problem (i fact, I currently encounter this problem): > If you do "evas_object_stack_above(obj, smart_object);" your object will > be stack above the smart object, but not necessarily above the member > objects of the smart object. In fact, it depends on how your smart > object and its member objects are ordered in the stack before the call. > > For example, if we have two objects: a smart object called S (and whose > member objects are called M1, M2, ...) and a "normal" object called O. > Here are two codes that should do the same but that do not because of > this problem: > (on the right is the order of the objects in the stack after each > function call) > > 1rst example: > evas_object_raise(S); --> "O M1 M2 ... S" > evas_object_stack_above(O, S); --> "M1 M2 ... S O" > So, with this example, object O appears indeed above the smart object > and its member objects. > > 2nd example: > evas_object_lower(S); --> "S M1 M2 ... O" > evas_object_stack_above(O, S); --> "S O M1 M2 ..." > Now, object O is indeed above the smart object, but not above its member > objects. > > I think the cleanest solution (and probably the easiest to implement > too) is to add two functions to smart objects: "lower_get" and > "above_get" which should respectively return the lower member object of > the smart object and the "higher" one (I don't know if "higher" is the > good english word: I mean the member object that is the most on the top > of the stack). Then, when we call stack_above(obj1, obj2) or > stack_below(obj1, obj2), we check if obj2 is a smart object, and if it > is, we call respectively obj2->above_get() and obj2->lower_get() to know > above or below which evas object we should really stack obj1. > > I don't know if I've been really clear, and I've probably said wrong > things :) > > Simon TRENY <MoOm> > > > Jose O Gonzalez a écrit : > > > 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 > > > > > > > > > -- ------------- 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
