> 1. An engine that can render to such a native surface buffer (rather
> than using the software argb buffer engine).
> 2. Implement evas image 'native surfaces' for the kinds of buffer
> surfaces you use in (1) above.
I should add that (2) isn't really needed for most uses, it'd
just be 'nice-to-have' for greatest flexibility and efficiency.
For example, for the opengl engine, one could have gl textures
for the 'surface' buffers, and then be able to use the gl api, or any
number of libs that support rtt, for custom rendered objects (ie. one
renders to such a buffer and uses that buffer as the 'data' of an image
obj, thus obtaining a custom rendered obj). Though for this to be truly
useful, it would likely be best used in conjuction with render_pre/post
functions of smart classes.
_____________________________________________________________
Love Music? Get a degree in Musical Education. Click Here.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oLWtvUT98gPPElJFfhvCV8rcyczR7UqpuVxQY2kdm82ElFu/
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
