On Sun, 21 Aug 2005 12:29:16 +0200 Simon writes:
> 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.
There are many situations where you would want to have smart
objects provide pre/post-render functions. Let me give you a *very*
simple example of one such.
Let's assume that you're an 'expert' on 3D graphics (I know
nothing about it myself), say you know lots about OpenGl or some
other 3D graphics lib, and you can get such a lib to 'render' 3D
scenes of various types or whatnot, to argb32 data that you provide.
You then create a lib which is based on an evas smart class
which will have only one member - an image object. Let's call the
evas smart objects this lib creates, 3D-objects.
You will have this lib have an api that allows you to set some
'global' lights that will affect the lighting of all 3D-objects you
create, and you will populate your 3D-objects by allowing some
3D-scene-format file to be 'set' on the 3D-objects you create, ie.
you will load this file and have the 3D rendering lib 'render' the
scene, relative to the global set of lights, onto the argb data
that will be set on the smart object's member image-object.
Ok, what happens when you move such a smart object? Well,
It's position relative to the global lights has changed and so
the 3D-object's appearance will change..
If evas has no way of telling you "we are now about to render
your object to the evas", or similar, then you will have to render
the 3D-scene *every time* you move the evas object, or make other
such state changes.
This is *very* expensive computationally - what you want to do
is render the 3D-scene *only* when evas is about to actually render
your smart member image-object to the evas.
If you could assign a pre-render function to the smart class
then this function would be called by evas at the start of the render
stage, and you could simply have this function render the 3D-scene
onto your argb data, and have evas set that as the image-object's
data. Then, after the pre-render stage is done, evas will get to the
render stage, where it will render the image-object, and so display
your 3D-scene on the evas.
Use your imagination and you can find inumerable ways of doing
just about anything.. but to have it do these efficiently, at least
as far as canvas-like rendering semantics is concerned, you need to
know when the canvas is actually about to render itself or to be
able to give the canvas instructions as to what to do then.
> 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.
>
This would easily become a never-ending proposition, as there
are always new and interesting 'objects' you might want.
Even the question of what is a 'primitive' is somewhat involved..
as is the question of wether or not one really needs to add the api
of such new objects to evas, wether the object could loadable at
runtime, or of how much access to the rendering internals it might
have, etc..
> 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.
>
Precisely. Setting the stacking order of the member objects,
the smart parent, or any other evas object.. does not worry about
wether or not the objects are 'members' or have 'members' or are
being placed between 'members', etc.
But functions related to getting 'stacking order' do care.
> 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.
>
That's a possibility :) But there are other things involved
as well, and in general the issue is really one of deciding wether
or not smart objects will truly 'own' their members -- ie. wether
the canvas will behave as a kind of window-system, so that the
stacking order of member objects is strictly local to the parent
object..
> I don't know if I've been really clear, and I've probably said wrong
> things :)
>
> Simon TRENY <MoOm>
>
Very clear, thanks for the feedback :)
jose.
>
> 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
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
