-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This one time, at band camp, Jose O Gonzalez wrote:
> From: Jose O Gonzalez <[EMAIL PROTECTED]>
> To: enlightenment-devel@lists.sourceforge.net
> Date: Wed, 17 Aug 2005 01:00:38 -0400
> Subject: [E-devel] Smart objects
>
>
> 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.
I cannot believe no one has responded to this. I am not going to pretend to have
an interesting response to this, but I can say that I did read your whole post
and you did have some interesting things to say. Perhaps you should stop by
#edevelop and discuss things with raster. At anyrate good stuff.
Stephen
- --
- ------------- Apó Mechanís Theós --------------
The Voidengineer (Stephen Horner) 悟
protocol.x at gmail.com
PGP 0xCDC2DD2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDBr5GRRkTWiD8QjIRAqgsAKCNjv12baKXTUK9dwYbmF05HgnaywCfZoNV
VuE2lfL7unX4ocukCiqlQb4=
=2pEo
-----END PGP SIGNATURE-----
-------------------------------------------------------
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
