On Sat, 21 Jul 2007, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 19 Jul 2007 00:20:16 +0200 "Jorge Luis Zapata Muga" > <[EMAIL PROTECTED]> babbled: > >> Hi all, i have taken evas to be my guinea pig here =) >> >> I've split the common engine code into a different library, because >> with time it has became a really good direct rendering library. what >> would it benefit us? i have the idea that abstracting at the canvas >> level and at the rendering level would make objects to render >> themselves, and get away from engine level several non needed stuff >> because there's maybe no engine that can do what evas do internally. >> the latter isnt fully decided yet, but isolating concepts on the >> library is a good thing imho, you can do more benchmarks and have more >> control on what every part of the library does. So the first step im >> doing is to abstract the direct rendering code, if anyone is >> interested on this, reply :) > > I think this is a good idea. I have nothing against it - but we need to be > aware that it makes breaking internal rendering api's harder :( i do agree > that > this will make benchmarks and testing of just raw routines much much much > easier. for now i think this extra lib can just ship with evas - we can split > it out later as/when needed. for now a big sign of "this api is going to break > - don't use it in your app unless you like api's always breaking" on it. :) again, a branch in cvs can be a good idea to test that. Vincent ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
