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 :) > 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 :) > > 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. > > 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. > > 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 > -- ------------- 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
