> As for implementation details, smart object is not the best option,
> actually using Evas as WebKit backend is not the best option around.
> ...
> ...
> So the best option is to draw to some buffer and use this as image
> data, then take care of event passing to this webkit engine. Using
> ...
Using smart objects has nothing to do with using evas built-in
primitives. A smart object, along with render-pre/post functions for
smart classes, may actually be your 'best' way to wrap that image
object to which you're setting the data - you would do your rendering
to the image data in the smart parent's render-pre function, and keep
any relevant state as part of your smart data.
With render-pre/post functions you could restrict any drawing
to the image data to when evas renders, redrawing only what areas need
it, and adding only those updates to the image object.
Alternatively, you can use buffer engine and a sub-canvas
as in done in ecore.
Yes, these are all doublle-buffered solutions, which has both
good and bad aspects... it's at its worst when things are constantly
animated.
But these are not going to be 'accelerated' solutions without
support for 'native surfaces' in evas image objects.
_____________________________________________________________
Click for free info on business schools, $150K/ year potential.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l7gMa49rDXuDBBJYXBgZ8bIpq5pi4CGeUjC3brt3TlCDbXS/
-------------------------------------------------------------------------
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
