http://arstechnica.com/news.ars/post/20080303-creating-rich-internet-applications-on-linux-with-webkit.html Hmmmmmm
On Sun, Mar 9, 2008 at 6:23 PM, The Rasterman Carsten Haitzler < [EMAIL PROTECTED]> wrote: > 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 > -- Veli Ogla Sungutay http://gui-rd.org ------------------------------------------------------------------------- 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
