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.
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.
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?
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
