On Thu, 6 Mar 2008 06:12:55 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > Carsten wrote: > > > ... what would be the right way would be to allow new extended > > objects (smart objects) to set rendering calls - the same way > > evas internal objects do, and then do their own rendering. > > breaking this out to a nice public api would be really nice and > > allow for objects built on a non-stateful (immediate mode) > > rendering model to exist and be efficient without HAVING to render > > to a buffer. this would mean breaking out the engine drawing calls > > and surface creation/destruction etc. into evas api. > > Yeah, would be good to have. But just getting render-pre/post > funcs for smarts, and implementing 'native surfaces' would be very > desirable as well, since buffered drawing is *very* useful for many > things. It's also easier to do, and needed in order to have engine- > specific sub-canvases. yup. i agree. native surface are important in the long run. > Either way, this would allow for engine-specific extensions > for evas.. wrapping things adequately would allow for things like > say an "evas3D" lib if really desired. sure. 3d INSIDE a "3d object" i can deal with in evas :) > I have a question for you on this though: I imagined having > 'native surface' image obj api given in each of the engine headers, > but you added a generic evas api for it.. What exactly do you have > in mind here? eg. say with gl-textures? literally evas exposing the engine drawing routines for that engine - generalised tho. gl i would expose as a generic api from a evas-3d lib on top of a native surface, but it would just abstrait to either software mesa or direct hardware opengl, so it'd work in a software canvas, just slowly. > There must be plenty of gl addicts out there who would love > to start doing their rtt 3D stuff with a gl-x11-evas. :) > > _____________________________________________________________ > Be your own boss today! Easy startup businesses. Click here. > http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l5i5ETtM15PrOl2jcouG108VB7tTMRbBeTCnS8KunaIB3Dq/ > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
