Hi Jose,
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
-------------------------------------------------------
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
