Re: [E-devel] EFL and Webkit
On Sat, 12 Apr 2008 01:53:16 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: Carsten wrote: But what I was curious about was what exactly you had in mind with your: typedef struct _Evas_Native_Surface Evas_Native_Surface; /** A generic datatype for engine specific native surface information */ EAPI void evas_object_image_native_surface_set(Evas_Object *obj, Evas_Native_Surface *surf); EAPI Evas_Native_Surface * evas_object_image_native_surface_get(Evas_Object *obj); for example. if it's the GL engine u can set a GL texture ID directly as the image native surface (u will need to provide extra info like width/height, has alpha etc. in a small wrapper struct), or a pixmap / xrender picture for x11 (again need to provide some extra info like visual, format etc.). so evas will Yeah, that's what I thought you meant - though there are other interpretations possible (eg. make a gl texture native surface work even with a software-x11 canvas, if glx is available, etc.). then take the target-specific native surface and just use it as if evas owned/created it itself. this is how u'd do a composite manager - xrender engine, you pass it pixmaps/xrender pictures for native sruface as images, you swallow images into containers and control them. on damage events u add update regions to the image. evas does the rest. What do you do if such a native surface is set and one asks for the argb data? What do you do about users setting native surfaces which don't match with the display targets somehow (differing x resources for example). I'd say - restrict native surface api to only have a 'get' func, ie. evas provides a suitable surface for you to draw to, but not for you to 'set' one such...? that would preclude evas ever being useful for a composite manager - as X itself provides you with the pixmap of the composited window. you don't have a choice there. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
What do you do if such a native surface is set and one asks for the argb data? What do you do about users setting native surfaces which don't match with the display targets somehow (differing x resources for example). I'd say - restrict native surface api to only have a 'get' func, ie. evas provides a suitable surface for you to draw to, but not for you to 'set' one such...? that would preclude evas ever being useful for a composite manager - as X itself provides you with the pixmap of the composited window. you don't have a choice there. Ummm... Ok, but it would then seem as though this little piece of native-surface image hell is going to be your fun and joy when you get a chance sometime in the near future..? :) PS. I noticed you've been conspicuously quiet on the 'transforms/ filters' debate I've been putting poor Gustavo thru.. :) I'd do it but not with arbitrary clipping, using transforms (or filters) and masks instead. But maybe it's better if others give it a shot. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
On Sat, 12 Apr 2008 03:15:46 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: What do you do if such a native surface is set and one asks for the argb data? What do you do about users setting native surfaces which don't match with the display targets somehow (differing x resources for example). I'd say - restrict native surface api to only have a 'get' func, ie. evas provides a suitable surface for you to draw to, but not for you to 'set' one such...? that would preclude evas ever being useful for a composite manager - as X itself provides you with the pixmap of the composited window. you don't have a choice there. Ummm... Ok, but it would then seem as though this little piece of native-surface image hell is going to be your fun and joy when you get a chance sometime in the near future..? :) PS. I noticed you've been conspicuously quiet on the 'transforms/ filters' debate I've been putting poor Gustavo thru.. :) I'd do it but not with arbitrary clipping, using transforms (or filters) and masks instead. But maybe it's better if others give it a shot. noticed i'm replying to old mails :) that thread is new... it needs some queueing first :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
On Mon, 10 Mar 2008 06:31:51 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: 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. Ummm I'm not sure I follow you here at all. What you've mentioned above seems far more reaching - not quite just dealing with implementing image obj 'native surfaces', which is what I was wondering about here. Maybe the other engine-ers (Cedric, Vincent, Gustavo) can give their own views here as well, but let me just be a bit more specific as to how I'd imagined this and see if it makes sense. engines have draw functions, like draw line draw polygon draw image (src rect, dest rect, scale mode) traw text with font X etc. etc. - these are internal between evas's canvas core and the engines. this is not exposed. if a smart object or Custom evas object can have access to these to draw - then either they can draw to a surface (image) using them OR they can draw directly to the canvas when an update render happens (and they get their paint() callback called - doesn't exist now, but hypothetically). By 'native surfaces' I'd meant things like xrender pictures, gl textures (maybe pbuffers), sdl surfaces, etc. So, more like engine- renderer specific 'buffer surfaces'. yup. One'd then have get/set functions for image objs of 'similar' evas engines (xrender-x11, gl-x11,...), along with various specialty funcs to query whatever extra stuff specific such 'surfaces' might have (eg. wether a gl texture is an nv-rect, its actual size, etc). Ideally, there would also be given a means to convert such surfaces to argb data (wether exposed or just internal). all images at some point use a native surface. software engines share the native surface with the original argb pixel data :) I'd imagined these funcs in each engine header, nothing at all in the general evas api, and one would implement the funcs in the engine modules, likely via the use of a new 'object function' to get an evas object's 'engine_data'. Or at least, that's more or less what I envisioned for these. Then go from there and build things like an evas-3D lib if desired.. possibly dependent on gl but able to render to any evas by say rendering to a gl buffer and getting argb data if need be, or some other way.. But what I was curious about was what exactly you had in mind with your: typedef struct _Evas_Native_Surface Evas_Native_Surface; /** A generic datatype for engine specific native surface information */ EAPI void evas_object_image_native_surface_set(Evas_Object *obj, Evas_Native_Surface *surf); EAPI Evas_Native_Surface * evas_object_image_native_surface_get(Evas_Object *obj); for example. if it's the GL engine u can set a GL texture ID directly as the image native surface (u will need to provide extra info like width/height, has alpha etc. in a small wrapper struct), or a pixmap / xrender picture for x11 (again need to provide some extra info like visual, format etc.). so evas will then take the target-specific native surface and just use it as if evas owned/created it itself. this is how u'd do a composite manager - xrender engine, you pass it pixmaps/xrender pictures for native sruface as images, you swallow images into containers and control them. on damage events u add update regions to the image. evas does the rest. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
Carsten wrote: But what I was curious about was what exactly you had in mind with your: typedef struct _Evas_Native_Surface Evas_Native_Surface; /** A generic datatype for engine specific native surface information */ EAPI void evas_object_image_native_surface_set(Evas_Object *obj, Evas_Native_Surface *surf); EAPI Evas_Native_Surface * evas_object_image_native_surface_get(Evas_Object *obj); for example. if it's the GL engine u can set a GL texture ID directly as the image native surface (u will need to provide extra info like width/height, has alpha etc. in a small wrapper struct), or a pixmap / xrender picture for x11 (again need to provide some extra info like visual, format etc.). so evas will Yeah, that's what I thought you meant - though there are other interpretations possible (eg. make a gl texture native surface work even with a software-x11 canvas, if glx is available, etc.). then take the target-specific native surface and just use it as if evas owned/created it itself. this is how u'd do a composite manager - xrender engine, you pass it pixmaps/xrender pictures for native sruface as images, you swallow images into containers and control them. on damage events u add update regions to the image. evas does the rest. What do you do if such a native surface is set and one asks for the argb data? What do you do about users setting native surfaces which don't match with the display targets somehow (differing x resources for example). I'd say - restrict native surface api to only have a 'get' func, ie. evas provides a suitable surface for you to draw to, but not for you to 'set' one such...? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
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. Ummm I'm not sure I follow you here at all. What you've mentioned above seems far more reaching - not quite just dealing with implementing image obj 'native surfaces', which is what I was wondering about here. Maybe the other engine-ers (Cedric, Vincent, Gustavo) can give their own views here as well, but let me just be a bit more specific as to how I'd imagined this and see if it makes sense. By 'native surfaces' I'd meant things like xrender pictures, gl textures (maybe pbuffers), sdl surfaces, etc. So, more like engine- renderer specific 'buffer surfaces'. One'd then have get/set functions for image objs of 'similar' evas engines (xrender-x11, gl-x11,...), along with various specialty funcs to query whatever extra stuff specific such 'surfaces' might have (eg. wether a gl texture is an nv-rect, its actual size, etc). Ideally, there would also be given a means to convert such surfaces to argb data (wether exposed or just internal). I'd imagined these funcs in each engine header, nothing at all in the general evas api, and one would implement the funcs in the engine modules, likely via the use of a new 'object function' to get an evas object's 'engine_data'. Or at least, that's more or less what I envisioned for these. Then go from there and build things like an evas-3D lib if desired.. possibly dependent on gl but able to render to any evas by say rendering to a gl buffer and getting argb data if need be, or some other way.. But what I was curious about was what exactly you had in mind with your: typedef struct _Evas_Native_Surface Evas_Native_Surface; /** A generic datatype for engine specific native surface information */ EAPI void evas_object_image_native_surface_set(Evas_Object *obj, Evas_Native_Surface *surf); EAPI Evas_Native_Surface * evas_object_image_native_surface_get(Evas_Object *obj); _ Can't pay your bills? Click here to learn about filing for bankruptcy. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nfvZ1HP2N7idMqB8psDhtwnNzca8Owk4iEEfc4EysHx9ahK/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
Carsten Haitzler (The Rasterman) wrote: 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 :) Exactly. Wrap things say a 3d-scene object and do your 3d stuff 'inside' such an object. One can do both immediate-mode and retained- mode kinds of rendering to such a scene object. For the latter type, one could have auxiliary 3d objects which must be 'bound' to such a scene, with coordinates rel to the scene obj,... eg. a 3d-scene object itself might be one such object that one could add to another, and ideally all evas primitives would also be added to such a 3d-scene object. One can extend evas in various ways by suitably having such objects which are like 'canvases' themselves that may support their own kinds of rendering/object system... things like 3d, svg, html, and many others are all possible in this way. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
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/vse012070mrt/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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
http://arstechnica.com/news.ars/post/20080303-creating-rich-internet-applications-on-linux-with-webkit.html Hmm 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/vse012070mrt/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/vse012070mrt/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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
On Wed, Mar 5, 2008 at 12:26 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: 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. enesim to rescue! that's our hope ;-) -- Gustavo Sverzut Barbieri http://ProFUSION.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
Le mardi 26 février 2008, vous avez écrit : 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. Great! I'm really interested in that project. 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. -- Raoul Hecky - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
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. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
