On Thu, 27 Oct 2005 11:33:05 +0900 Carsten writes:
> On Wed, 26 Oct 2005 18:42:48 -0400 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> >
> >
> > On Thu, 27 Oct 2005 00:25:12 +0900 Carsten writes:
> > > OK everyone - developer beings and such.
> > >
> > > as was brought up on the mailing lists several months ago,
> > > i have (FINALLY!) started some work on cleaning/rationalising
> > > and improving eva's smart object code and interfaces.
> >
> > And there is much rejoicing! :)
>
> :)
>
> > > my first step is to move smart object child objects within
> > > the smart object itself - making the object struct less flat and
>
> > > more tree-like. this shoudl mean some speedups too.
> >
> > Yes. Also, though not smart-obj related -- since clip-objs
> > should have only *one* clipee, it would make sense to let a
> > clipped obj 'own' its clipper as well.. ie. remove clippers from
> > the layers as well.
>
> yes - that would make sense. they even dont require any stacking
> order as a
> clip does not affect stacking (currently) :) but that may change (ie
> set the
> "merge buffer" option (which doesnt exist yet) on an object that is
> a clipper
> then all objects clipped will be first rendered into a tmp buffer
> THEN when the
> buffer is merged with the main drawn tree (or a parent buffer) is
> the clip mask
> applied. - example (as you were saying before - api-wise we are able
> to add it
> trivially. its the engine side that will have issues)
>
> what i REALLY want though is to reduce the side of clippee lists
> simple by
> havign all child objects of a smart be clipped by the clipper OF a
> smart object
> automatically :)
>
A large gain there for many reasons :)
> > Also not smart obj related, but a small, easy optimization
> > in most cases -- have an internal canvas render function of the
> > form:
> >
> > Evas_List *_evas_render(Evas *evas, char return_updates);
> >
> > so that the api's render function which *does not* return updates,
> > can be defined via the above -- with 'return_updates' set to 0.
> > When this is 0-set, the _evas_render function can avoid creating
> > the list of rect updates (that the evas_render function can't
> > return anyway and just has to free).
>
> while technically an optimisation, in practice - you will never
> measure any
> speedup as the overhead of a malloc and list append per region per
> render cycle
> is in the realm of < 0.00001% of the grunt needed to render :)
>
Yeah.. But remember the old saying "...every little bit helps..."
and if it's a freebie like this one, then what the heck! :)
Also unlikely to have any affect most times, but that perhaps
could be a simplification of things:
I don't see why there's a need to build a separate list of
"restack objs" (in the render function)? This seems to be simply
something that should be done in each obj's render_pre func,
ie. like:
if (obj->changed)
{
...
if (obj->restack)
// add cur-prev updates and goto done..
...
}
> > > i also plan on removing the need for clip/unclip, show/hide
> > > and color_set methods so they are no longer used.
> > > that will be step 2.
> >
> > And again there is much rejoicing! :)
> >
> > I would suggest adding render-pre and post methods though,
> > as they could be very useful for more 'self-rendering' types of
> > smart objs. The obj's render-pre and post functions have to be
> > called anyway, just to recurse calling their childrens', so might
> > as well have user provided ones in addition...
> > Of course this could also cause all kinds of havoc... :(
>
> right now i dont plan on extending smart objects to be able to
> directly render
> (yet) as that would require exporting the immediate-mode rendering
> api to them
> - even calling the render of a sub object is not that useful as
> well- it can
> call it itself :) but the idea of the class struct is that in FUTURE
> we can add
> "render" smart calls that if set to non-NULL will allow a smart obj
> to provide
> direct rendering calls of its own - effectively becoming an extended
> object.
>
Yes.. But the idea behind render_pre and render_post functions,
for smart-objs, is to allow their designer to defer whatever expensive
calculations til render time, ie. so they can also have the ability
to keep cur/prev states of properties that they may only wish to
re-calculate at each rendering instance - even if they can't render
to the actual target engine surface :)
> > > step 3 will be removal of evas_smart_new()
> > > in favor of using evas_smart_class_new() as it uses an
> extendible
> > > struct interface. i have marked methods for deletion for now too
> > > in that.
> >
> > Well, this will go a loooong way to solve many of the
> major
> > problems with these :)
> >
> > What about the event system?
>
> i have adjusted it to account for the different object list
> structure :) works
> as before though :) i'm trying small changes atm to minimise break.
>
Right :) :)
> > > so... that means if you have made smart objects... you will need
> to
> > > do a little adapting soon. but in the long run it will make
> things
> > > much simpler, cleaner and more expandable.
> >
> > Yes :)
> >
> > > i am still tossing up if the smart move method should be there,
> or
> > > all child
> > > objects should be simply placed rlative to the smart parent's
> origin
> > > and thus
> > > moved automatically, or if i should provide a default move
> method
> > > that does
> > > this for you. right now its save from destruction - but i'm
> tossing
> > > up as to
> > > the future of it.
> > >
> > > another thing to go soon will be the old textblock api -
> consider it
> > > dead as of
> > > today, and only hanging in evas in cvs as long as i simply dont
> get
> > > around to
> > > removing it. if you are using textblock2 - it will be RENAMED to
>
> > > textblock once
> > > this happens. this will cause a short period of breakage as
> things
> > > move over,
> > > but then transition will be finished.
> > >
> > > so - be warned... :) and enjoy the newness! :)
> > >
> > > --
> > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > --------------
> > > The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
> > > 裸好多
> > > Tokyo, Japan (東京 日本)
> > >
> > >
> >
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
