On Mon, 25 Feb 2008 23:50:41 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> On Mon, Feb 25, 2008 at 9:09 PM, raoul <[EMAIL PROTECTED]> wrote: > > Hi there, > > > > I think there is a great stuff missing in efls, it's a web rendering > > engine. The main purpose would be to have a full-efl based web browser. But > > also have some web rendering inside Evas/Edje based apps. This could really > > be awsome. > > > > I started to search how to have such capability and there are not many > > options. The first one could be to write our own, from scratch. This would > > probably be a huge task to do. I don't think it's the way. > > > > The second idea is to use Webkit as the web engine. It seems to be a good > > engine with great performance, compatibility and standards compliance. > > My idea would be to write an Evas smart object which will do the rendering > > stuff using webkit and expose some nice functions to the user like > > load_url(), reload_page(), ... > > The rendering process will use Evas. I check a little the webkit code, ans > > it seems like it could be done. Perhaps some rendering part would need some > > Evas modifications, I don't know yet. But it should not be impossible to do. > > > > Having all of that right into a new library (e_web?) could reallly be a > > great improvement to Efl's power. > > Eh, you're not the first one to notice it :-) > > INdT is working on such a library. Albeit I did the initial "route > planing" I couldn't keep a closer eye on it due heavy work on Canola2, > but I think they have some progress on that. I'll try to ask what's > the project status so far and possible a snapshot. > > As for implementation details, smart object is not the best option, > actually using Evas as WebKit backend is not the best option around. > Why? The major problem is that webkit is state-less, while evas is > state-full. Also webkit requires just few primitives in order to > render, you just have to implement the advanced primitives if you want > SVG loader and Canvas support, other than that it just render simple > (continuous, same font, effect, size...) text at some given position, > rectangles and images... It does the layout, line breaking, ... > 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 > this solution have one major drawback: if you have some animation, it > would require 2 blits instead of one (one to buffer, then from buffer > to screen), but this allow you to play with primitives as scale, color > modulation (fade out, colorize, ....) and clip some regions. yeah - thats probably the best way to do it. the other way would be as an actual extension to evas and as a core object in evas. this would make evas dependent on webkit 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. after that u can more easily implement a webkit object that draws natively really nicely and in theory could use hardware accel to do it with gl, xrender etc. engines. -- ------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
