Re: [E-devel] RFC gradient clip
On 5/27/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: I'm not sure about overhead, need to evaluate on small/embedded devices (I'm more than surprised by the bottlenecks I've found while running on omap2420/arm6/maemo). As for API, most places uses Evas_Coord, which now is typedef'ed to int but some code I read uses 0.0, so maybe it it's/was designed to run as float if desired. There is even a translation of world-evas coordinates, now it's dummy. Evas_Coord was originally defined as a float, so you may see a few remnants like that. Also there was originally support for non one-to-one mappings of evas coordinate space to world coordinates. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Mon, 2007-28-05 at 21:14 -0500, Nathan Ingersoll wrote: Evas_Coord was originally defined as a float, so you may see a few remnants like that. Also there was originally support for non one-to-one mappings of evas coordinate space to world coordinates. Do you know the reason for the change to int? Was it just because none of the engines took advantage of it? Obviously I'd like to see Evas_Coord be a float. :) But perhaps the reason for the change to int is indicative of a deeper problem. Cheers, Jason. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On 5/28/07, Jason Tackaberry [EMAIL PROTECTED] wrote: Do you know the reason for the change to int? Was it just because none of the engines took advantage of it? Obviously I'd like to see Evas_Coord be a float. :) But perhaps the reason for the change to int is indicative of a deeper problem. IIRC, the change to integer math was a significant speed improvement, especially on architectures without hardware floating point support. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Tue, 2007-08-05 at 15:28 -0400, Jason Tackaberry wrote: 3. Lack of subpixel precision. Makes stuff like the Ken Burns Effect impossible (or possible, but lame). However this is probably not practical without a big evas rewrite. I was thinking about this ... it sounds like a lot of manual labor, but wouldn't this just be a matter of changing the API and structs and certain relevant internal functions to use float instead of int for geometry? Then the engines can either use the float precision or ignore it. e.g. for the GL engine, change glVertex2i calls to glVertex2f. I suppose there would be some overhead with casting floats to ints for those engines that don't implement subpixel precision, but I don't think this would be a significant. Comments? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On 5/28/07, Jason Tackaberry [EMAIL PROTECTED] wrote: On Tue, 2007-08-05 at 15:28 -0400, Jason Tackaberry wrote: 3. Lack of subpixel precision. Makes stuff like the Ken Burns Effect impossible (or possible, but lame). However this is probably not practical without a big evas rewrite. I was thinking about this ... it sounds like a lot of manual labor, but wouldn't this just be a matter of changing the API and structs and certain relevant internal functions to use float instead of int for geometry? Then the engines can either use the float precision or ignore it. e.g. for the GL engine, change glVertex2i calls to glVertex2f. I suppose there would be some overhead with casting floats to ints for those engines that don't implement subpixel precision, but I don't think this would be a significant. I'm not sure about overhead, need to evaluate on small/embedded devices (I'm more than surprised by the bottlenecks I've found while running on omap2420/arm6/maemo). As for API, most places uses Evas_Coord, which now is typedef'ed to int but some code I read uses 0.0, so maybe it it's/was designed to run as float if desired. There is even a translation of world-evas coordinates, now it's dummy. -- 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 DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
about that, why not doing a branch in cvs ? Branches exist for that kind of stuff. a perfectly sane idea. we use branches rarely - but this is a case where it would be good. we should add jose to the cvs access/devs. jose - if you want, send me your ssh public key (id_dsa.pub in ~/.ssh) then fill in this developer info form: Login:??? IRC Nick: ??? Name: ??? Location: ??? E-Mail: ??? WWW: ??? Managing: ??? That might be a good idea, evas internals do need a fairly large reworking if the lib is to be able to expand in capabilities, and it may also lead to other work being done that might not otherwise be attempted. As to cvs access for me... Well, as you know Carsten, this is something I've not wanted (for several reasons we don't need to go into here). It's been a bit of a pain for both of us sure, but so it goes.. :( Maybe at a later point in time. I'm going to take a month away, or maybe two, for now.. hopefully some interesting stuff (besides in evas or e17) will be further explored over that time. :) [eg. Simon's 'glade-like' ideas, and I think a good 'desklets' lib of some sort (with a suitable description format) that would allow for edje based gadgets (not tied exclusively to e17 please) like clocks, rss-feeds, maybe a simple text-entry gidget, and things of that sort.. would be useful and interesting. Maybe a list of ideas/projects/needs/... that e as a whole could benefit from would be good thing for people to stare at.. ] See you in a bit. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Sat, 12 May 2007 07:16:23 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Carsten wrote: the advice is i would like this and it would be good but its not trivial to do right/well and right now i really don't have the time to do it - thus it's one of those backburner when i get to it things. Ahhh... Well, if you're going to do it.. then I'll just leave it be. :) i might not get to it... for years! :) this basically was saying it's a desired feature - so don't give up - but i don't have time now to look into it :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Tue, 15 May 2007 10:29:49 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Gustavo wrote: I want to know how difficult would be to implement support for clip using gradient objects. ... ... We are willing to implement it if you give us some hints :-) Just thought I'd go back to this a bit here, and see if I can give you an idea of what's 'really' needed for this. The way Carsten setup clip-object semantics in evas is that any object can clip any other, and this can be arbitrarily iterated (since a clip object can have a clip object as well). Also, an object can clip any number of objects. It's a very nice idea, though with that kind of generality it's going to be tough to do anything involved very efficiently. However, the real problem in evas right now is just trying to get this implemented *at all*. The way the internals are set up, it's just not feasible.. and neither is doing *anything* much beyond what raster initially set things up for (eg. rotations or any kind of transforms on image objs.. just can't really be 'done' right now, no matter how 'easy' it might be to accomplish that with any of the gfx backends). I've pointed this out several times in the past, but let me explain in a bit more detail exactly why this situation exists and what's needed to correct it. The canvas level has a structure that holds the state for an evas object (eg. size, clip-obj, etc). This structure also has a pointer to any type specific state (ie. things for rects, images, etc). It also has a pointer to a 'render' function that is called whenever a given object needs to be drawn - this function is given for each specific type of object, and has a generic form, eg. draw something to some dst at some point... and such things. The way these object render functions are obtained is in turn via certain other 'engine functions' which are implemented by the various engines, ie. by the various rendering backends. The problem is that this set of 'engine functions' then defines an immediate mode rendering api which is ALL that the canvas can work with. It ties the canvas lib's capabilities to the specific rendering model/api that this set of interfaces defines. Unfortunately, the current such interfaces, ie. the rendering model.. is extremely limited. That's the source of all the problems that evas faces right now as far as extending its capabilities to allow for such things as obj transforms, clipping, texturing, and any number of other gfx aspects. a very good summary/analysis :) Now, one can say Well, let's use eg. a vgfx rendering model, that's a powerful one..., or maybe say No, let's use a compositing rendering model, it's more flexible yet smaller..., or any number of other things.. and how is one to choose? (and the choice must make it easy for it to be realized with various other gfx libs. eg. xrender, gl, cairo, ...) Very easily: Let the canvas api be the rendering model, rather than impose some other. After all, what one wants is to modify 'obj' state, setup things, and draw the 'obj' as need be. the only problem is - this makes engines a lot bigger and more complex. What that means is that one needs to push all relevant canvas level 'object' state down to the engines level, and let things be implemented there as each 'engine' sees fit. Do this, and all the things everyone wants for evas to be able to do, and things that no one has maybe even thought of... will at least be feasible to *attempt* to implement. It simply isn't feasible or reasonable right now to even try otherwise. we do need to push more of it down - but i am not sure we should push it all down. the engine api imho is still best being an immediate-mode api. we just need to expand it more or re-factor it to deal with new operations. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list
Re: [E-devel] RFC gradient clip
On Tue, 15 May 2007 21:33:29 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: The way Carsten setup clip-object semantics in evas is that any object can clip any other, and this can be arbitrarily iterated (since a clip object can have a clip object as well). Also, an object can clip any number of objects. right now clip is all about rectangle operations to limit the visible are... or is anything else supported? Nothing else is 'supported' except plain rectangles, but it was intended as decribed.. and the canvas level does try. :) yup. canvas level was kept ultra-generic for the future where inside evas and the engines they got the ability to generate clip mask buffers and intermediate render buffers and use them. The way the internals are set up, it's just not feasible.. and neither is doing *anything* much beyond what raster initially set things up for (eg. rotations or any kind of transforms on image objs.. just can't really be 'done' right now, no matter how 'easy' it might be to accomplish that with any of the gfx backends). I don't get what you mean with rotations/transitions. If clip object is rotated, then you'd consider it rotated and you're done, just like you get its current size. In order to minimize work, we could do regular bounding box clip and when to process scanlines, segment it into intervals, these to be segmented by the next clip object and so on... In the end you get the continuous segments you would blit/blend/transform (in the gradient case). That's one way, software-wise. But it's just not the issue here. Do this, and all the things everyone wants for evas to be able to do, and things that no one has maybe even thought of... will at least be feasible to *attempt* to implement. It simply isn't feasible or reasonable right now to even try otherwise. Well... moving everything to engine will leave us with just a common API and very different implementations, that will be really extensible, trade off is consistency, complexity and possible more. If we extend clip to be any polygon or curve (if we allow ellipses, circles, ... in future) and also enable cumulative transformations we can do many things without all that pain. The former is not difficult, since well known algorithms exists, the later is more related to implementation details, while I know it's possible to do JIT and remove overhead of functions, just getting the operations on i686+software_x11, I'm not sure if it fits other sytems (GL?)... if we trade off memory in favor of performance we can always render to an auxiliary buffer and then do some operation (sub, add, or, and, mul, ...) while rendering clipped objs. That's my understandings so far, I don't know any engine or even the API that well, if I'm wrong just let me know. Well, you see.. the issue here isn't really about being able to implement things with software algorithms, or with some other gfx backend (gl or xrender or cairo or whatever). All that can be done. The problem is that evas just won't let you even try, not without extensively rewriting a large amount of things. Again, the way the internals are setup, every evas object calls a generic 'render' function to draw itself.. and this is an abstract kind of function since the rendering target and the rendering mechanisms can vary (different engines). But, this render function doesn't get directly implemented by the rendering backends. Instead, it uses a set of abstract 'engine functions' which are themselves what get implemented by each rendering backend. Those functions are what the canvas can use to draw an evas object.. and ONLY those functions. the problem here is - this begins to break down for things like textblock - you do NOT want to implement that in the engine. the object render func is probably the best design. for simple objects (rect, even objects) it might be ok to put n the engine. Let's take your example of an 'evas_object_transform_set' api function that you want. Ok, when you come to actually implement this, you will add some 'transform' to the evas object structure so that all objects keep the transform state. Then, when the canvas calls the object's render function it needs to draw the transformed object.. so in each object's render function you need to 'implement' the drawing of such a trnasformed object. But, you can only call 'engine functions' for this.. that's ALL you can work with. Suppose you then want to be able to set a 'filter' object on an evas object, eg. to blur, bumpmap, ... an object. Again, you will add such state to the evas object structure and in each object's render function you need to 'implement' the drawing of such an object with such a filter, and with the transform you wanted for the object before, and maybe the filter
Re: [E-devel] RFC gradient clip
On Wed, 16 May 2007 07:53:01 +0200 (CEST) Vincent Torri [EMAIL PROTECTED] babbled: On Tue, 15 May 2007, Gustavo Sverzut Barbieri wrote: On 5/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I should've added: and that involves a very large rewrite of the engine level internals. There is no way to avoid this -- if one wants evas to be able to do much of anything beyond what it now does. It's what I've been working on recently.. but it's a large amount of work - in itself not necessarily 'difficult', but a lot.. with many, many details. Not to mention that I had to work out a fair amount of other things, like a reasonable mechanism to do such clipping, and image fill-transforms, and textured stroke/fill of rounded rects, and try and figure out a better way to deal with styled-text (eg. something like what I did sometime back with imlib2 text-styling), and clean-up and improve a bunch of things... And it's going to take yet more time and work to finish off a lot of it still. Great you're already doing it, at least it will serve as reference if not integrated/used... is there any CVS/SVN/GIT/... we can follow and do some testing? about that, why not doing a branch in cvs ? Branches exist for that kind of stuff. a perfectly sane idea. we use branches rarely - but this is a case where it would be good. we should add jose to the cvs access/devs. jose - if you want, send me your ssh public key (id_dsa.pub in ~/.ssh) then fill in this developer info form: Login:??? IRC Nick: ??? Name: ??? Location: ??? E-Mail: ??? WWW: ??? Managing: ??? Vincent - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Wed, 16 May 2007 04:12:44 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Gustavo wrote: Great you're already doing it, at least it will serve as reference if not integrated/used... is there any CVS/SVN/GIT/... we can follow and do some testing? None except my local copy.. and as it's partly working, partly in the process of being worked out.. until I feel that it's something that's complete enough to be 'usable', it'll likely stay that way. It may well stay that way in any case, if there's little or no interest in having this in evas. In fact, given raster's recent remarks on this, I'm rather inclined to just let it go as of now. It'll have to wait til he decides to get to it instead. :) i'm interested :) definitely! but i just dont have time to really work on it :( i wish i did. if we put this in cvs it's open and visible. likely vincent and gustavo will be interested. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Gustavo wrote: I want to know how difficult would be to implement support for clip using gradient objects. ... ... We are willing to implement it if you give us some hints :-) Just thought I'd go back to this a bit here, and see if I can give you an idea of what's 'really' needed for this. The way Carsten setup clip-object semantics in evas is that any object can clip any other, and this can be arbitrarily iterated (since a clip object can have a clip object as well). Also, an object can clip any number of objects. It's a very nice idea, though with that kind of generality it's going to be tough to do anything involved very efficiently. However, the real problem in evas right now is just trying to get this implemented *at all*. The way the internals are set up, it's just not feasible.. and neither is doing *anything* much beyond what raster initially set things up for (eg. rotations or any kind of transforms on image objs.. just can't really be 'done' right now, no matter how 'easy' it might be to accomplish that with any of the gfx backends). I've pointed this out several times in the past, but let me explain in a bit more detail exactly why this situation exists and what's needed to correct it. The canvas level has a structure that holds the state for an evas object (eg. size, clip-obj, etc). This structure also has a pointer to any type specific state (ie. things for rects, images, etc). It also has a pointer to a 'render' function that is called whenever a given object needs to be drawn - this function is given for each specific type of object, and has a generic form, eg. draw something to some dst at some point... and such things. The way these object render functions are obtained is in turn via certain other 'engine functions' which are implemented by the various engines, ie. by the various rendering backends. The problem is that this set of 'engine functions' then defines an immediate mode rendering api which is ALL that the canvas can work with. It ties the canvas lib's capabilities to the specific rendering model/api that this set of interfaces defines. Unfortunately, the current such interfaces, ie. the rendering model.. is extremely limited. That's the source of all the problems that evas faces right now as far as extending its capabilities to allow for such things as obj transforms, clipping, texturing, and any number of other gfx aspects. Now, one can say Well, let's use eg. a vgfx rendering model, that's a powerful one..., or maybe say No, let's use a compositing rendering model, it's more flexible yet smaller..., or any number of other things.. and how is one to choose? (and the choice must make it easy for it to be realized with various other gfx libs. eg. xrender, gl, cairo, ...) Very easily: Let the canvas api be the rendering model, rather than impose some other. After all, what one wants is to modify 'obj' state, setup things, and draw the 'obj' as need be. What that means is that one needs to push all relevant canvas level 'object' state down to the engines level, and let things be implemented there as each 'engine' sees fit. Do this, and all the things everyone wants for evas to be able to do, and things that no one has maybe even thought of... will at least be feasible to *attempt* to implement. It simply isn't feasible or reasonable right now to even try otherwise. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On 5/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Gustavo wrote: I want to know how difficult would be to implement support for clip using gradient objects. ... ... We are willing to implement it if you give us some hints :-) Just thought I'd go back to this a bit here, and see if I can give you an idea of what's 'really' needed for this. good! :-) I won't reply every item as I want to wait for raster and possible others to step in and comment, so I can learn a bit more, but few things are: The way Carsten setup clip-object semantics in evas is that any object can clip any other, and this can be arbitrarily iterated (since a clip object can have a clip object as well). Also, an object can clip any number of objects. right now clip is all about rectangle operations to limit the visible are... or is anything else supported? It's a very nice idea, though with that kind of generality it's going to be tough to do anything involved very efficiently. However, the real problem in evas right now is just trying to get this implemented *at all*. The way the internals are set up, it's just not feasible.. and neither is doing *anything* much beyond what raster initially set things up for (eg. rotations or any kind of transforms on image objs.. just can't really be 'done' right now, no matter how 'easy' it might be to accomplish that with any of the gfx backends). I don't get what you mean with rotations/transitions. If clip object is rotated, then you'd consider it rotated and you're done, just like you get its current size. In order to minimize work, we could do regular bounding box clip and when to process scanlines, segment it into intervals, these to be segmented by the next clip object and so on... In the end you get the continuous segments you would blit/blend/transform (in the gradient case). I've pointed this out several times in the past, but let me explain in a bit more detail exactly why this situation exists and what's needed to correct it. The canvas level has a structure that holds the state for an evas object (eg. size, clip-obj, etc). This structure also has a pointer to any type specific state (ie. things for rects, images, etc). It also has a pointer to a 'render' function that is called whenever a given object needs to be drawn - this function is given for each specific type of object, and has a generic form, eg. draw something to some dst at some point... and such things. The way these object render functions are obtained is in turn via certain other 'engine functions' which are implemented by the various engines, ie. by the various rendering backends. The problem is that this set of 'engine functions' then defines an immediate mode rendering api which is ALL that the canvas can work with. It ties the canvas lib's capabilities to the specific rendering model/api that this set of interfaces defines. Unfortunately, the current such interfaces, ie. the rendering model.. is extremely limited. That's the source of all the problems that evas faces right now as far as extending its capabilities to allow for such things as obj transforms, clipping, texturing, and any number of other gfx aspects. Now, one can say Well, let's use eg. a vgfx rendering model, that's a powerful one..., or maybe say No, let's use a compositing rendering model, it's more flexible yet smaller..., or any number of other things.. and how is one to choose? (and the choice must make it easy for it to be realized with various other gfx libs. eg. xrender, gl, cairo, ...) Very easily: Let the canvas api be the rendering model, rather than impose some other. After all, what one wants is to modify 'obj' state, setup things, and draw the 'obj' as need be. ok, so far it makes sense. What that means is that one needs to push all relevant canvas level 'object' state down to the engines level, and let things be implemented there as each 'engine' sees fit. here I need some clarification. How do you see these in use? How do you see x, y, w, h, alpha already being in the engine help? Do this, and all the things everyone wants for evas to be able to do, and things that no one has maybe even thought of... will at least be feasible to *attempt* to implement. It simply isn't feasible or reasonable right now to even try otherwise. Well... moving everything to engine will leave us with just a common API and very different implementations, that will be really extensible, trade off is consistency, complexity and possible more. If we extend clip to be any polygon or curve (if we allow ellipses, circles, ... in future) and also enable cumulative transformations we can do many things without all that pain. The former is not difficult, since well known algorithms exists, the later is more related to implementation details, while I
Re: [E-devel] RFC gradient clip
The way Carsten setup clip-object semantics in evas is that any object can clip any other, and this can be arbitrarily iterated (since a clip object can have a clip object as well). Also, an object can clip any number of objects. right now clip is all about rectangle operations to limit the visible are... or is anything else supported? Nothing else is 'supported' except plain rectangles, but it was intended as decribed.. and the canvas level does try. :) The way the internals are set up, it's just not feasible.. and neither is doing *anything* much beyond what raster initially set things up for (eg. rotations or any kind of transforms on image objs.. just can't really be 'done' right now, no matter how 'easy' it might be to accomplish that with any of the gfx backends). I don't get what you mean with rotations/transitions. If clip object is rotated, then you'd consider it rotated and you're done, just like you get its current size. In order to minimize work, we could do regular bounding box clip and when to process scanlines, segment it into intervals, these to be segmented by the next clip object and so on... In the end you get the continuous segments you would blit/blend/transform (in the gradient case). That's one way, software-wise. But it's just not the issue here. Do this, and all the things everyone wants for evas to be able to do, and things that no one has maybe even thought of... will at least be feasible to *attempt* to implement. It simply isn't feasible or reasonable right now to even try otherwise. Well... moving everything to engine will leave us with just a common API and very different implementations, that will be really extensible, trade off is consistency, complexity and possible more. If we extend clip to be any polygon or curve (if we allow ellipses, circles, ... in future) and also enable cumulative transformations we can do many things without all that pain. The former is not difficult, since well known algorithms exists, the later is more related to implementation details, while I know it's possible to do JIT and remove overhead of functions, just getting the operations on i686+software_x11, I'm not sure if it fits other sytems (GL?)... if we trade off memory in favor of performance we can always render to an auxiliary buffer and then do some operation (sub, add, or, and, mul, ...) while rendering clipped objs. That's my understandings so far, I don't know any engine or even the API that well, if I'm wrong just let me know. Well, you see.. the issue here isn't really about being able to implement things with software algorithms, or with some other gfx backend (gl or xrender or cairo or whatever). All that can be done. The problem is that evas just won't let you even try, not without extensively rewriting a large amount of things. Again, the way the internals are setup, every evas object calls a generic 'render' function to draw itself.. and this is an abstract kind of function since the rendering target and the rendering mechanisms can vary (different engines). But, this render function doesn't get directly implemented by the rendering backends. Instead, it uses a set of abstract 'engine functions' which are themselves what get implemented by each rendering backend. Those functions are what the canvas can use to draw an evas object.. and ONLY those functions. Let's take your example of an 'evas_object_transform_set' api function that you want. Ok, when you come to actually implement this, you will add some 'transform' to the evas object structure so that all objects keep the transform state. Then, when the canvas calls the object's render function it needs to draw the transformed object.. so in each object's render function you need to 'implement' the drawing of such a trnasformed object. But, you can only call 'engine functions' for this.. that's ALL you can work with. Suppose you then want to be able to set a 'filter' object on an evas object, eg. to blur, bumpmap, ... an object. Again, you will add such state to the evas object structure and in each object's render function you need to 'implement' the drawing of such an object with such a filter, and with the transform you wanted for the object before, and maybe the filter itself admits transforms, and maybe you have the object clipped by an image object and this image object has borders, and is itself transformed in some way, and possibly another filter is being applied to it, and the image object has another clip object which is a path which is and the object you're drawing is a rounded recangle, which is to be stroked with some color and filled with some gradient texture, and the gradient is a radial one, and is trasnformed in some way, and... And all this you have to 'implement' via the set of engine functions beacuse
Re: [E-devel] RFC gradient clip
I wrote: Let's take your example of an 'evas_object_transform_set' api function that you want. Ok, when you come to actually implement this, you will add some 'transform' to the evas object structure so that all objects keep the transform state. Then, when the canvas calls the object's render function it needs to draw the transformed object.. so in each object's render function you need to 'implement' the drawing of such a trnasformed object. But, you can only call 'engine functions' for this.. that's ALL you can work with. Suppose you then want to be able to set a 'filter' object on an evas object, eg. to blur, bumpmap, ... an object. Again, you will add such state to the evas object structure and in each object's render function you need to 'implement' the drawing of such an object with such a filter, and with the transform you wanted for the object before, and maybe the filter itself admits transforms, and maybe you have the object clipped by an image object and this image object has borders, and is itself transformed in some way, and possibly another filter is being applied to it, and the image object has another clip object which is a path which is and the object you're drawing is a rounded recangle, which is to be stroked with some color and filled with some gradient texture, and the gradient is a radial one, and is trasnformed in some way, and... And all this you have to 'implement' via the set of engine functions beacuse that's ALL that the canvas can access to do anything. That set of engine functions is the canvas' gfx api, not the actual engine gfx backend apis. See the problem? Fortunately, there is a way to do this. :) I should've added: and that involves a very large rewrite of the engine level internals. There is no way to avoid this -- if one wants evas to be able to do much of anything beyond what it now does. It's what I've been working on recently.. but it's a large amount of work - in itself not necessarily 'difficult', but a lot.. with many, many details. Not to mention that I had to work out a fair amount of other things, like a reasonable mechanism to do such clipping, and image fill-transforms, and textured stroke/fill of rounded rects, and try and figure out a better way to deal with styled-text (eg. something like what I did sometime back with imlib2 text-styling), and clean-up and improve a bunch of things... And it's going to take yet more time and work to finish off a lot of it still. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On 5/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I should've added: and that involves a very large rewrite of the engine level internals. There is no way to avoid this -- if one wants evas to be able to do much of anything beyond what it now does. It's what I've been working on recently.. but it's a large amount of work - in itself not necessarily 'difficult', but a lot.. with many, many details. Not to mention that I had to work out a fair amount of other things, like a reasonable mechanism to do such clipping, and image fill-transforms, and textured stroke/fill of rounded rects, and try and figure out a better way to deal with styled-text (eg. something like what I did sometime back with imlib2 text-styling), and clean-up and improve a bunch of things... And it's going to take yet more time and work to finish off a lot of it still. Great you're already doing it, at least it will serve as reference if not integrated/used... is there any CVS/SVN/GIT/... we can follow and do some testing? -- 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 DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Gustavo wrote: Great you're already doing it, at least it will serve as reference if not integrated/used... is there any CVS/SVN/GIT/... we can follow and do some testing? None except my local copy.. and as it's partly working, partly in the process of being worked out.. until I feel that it's something that's complete enough to be 'usable', it'll likely stay that way. It may well stay that way in any case, if there's little or no interest in having this in evas. In fact, given raster's recent remarks on this, I'm rather inclined to just let it go as of now. It'll have to wait til he decides to get to it instead. :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Tue, 15 May 2007, Gustavo Sverzut Barbieri wrote: On 5/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I should've added: and that involves a very large rewrite of the engine level internals. There is no way to avoid this -- if one wants evas to be able to do much of anything beyond what it now does. It's what I've been working on recently.. but it's a large amount of work - in itself not necessarily 'difficult', but a lot.. with many, many details. Not to mention that I had to work out a fair amount of other things, like a reasonable mechanism to do such clipping, and image fill-transforms, and textured stroke/fill of rounded rects, and try and figure out a better way to deal with styled-text (eg. something like what I did sometime back with imlib2 text-styling), and clean-up and improve a bunch of things... And it's going to take yet more time and work to finish off a lot of it still. Great you're already doing it, at least it will serve as reference if not integrated/used... is there any CVS/SVN/GIT/... we can follow and do some testing? about that, why not doing a branch in cvs ? Branches exist for that kind of stuff. Vincent - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Carsten wrote: the advice is i would like this and it would be good but its not trivial to do right/well and right now i really don't have the time to do it - thus it's one of those backburner when i get to it things. Ahhh... Well, if you're going to do it.. then I'll just leave it be. :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On 5/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Carsten wrote: the advice is i would like this and it would be good but its not trivial to do right/well and right now i really don't have the time to do it - thus it's one of those backburner when i get to it things. Ahhh... Well, if you're going to do it.. then I'll just leave it be. :) Well... raster is just one (busy) guy, we could help with some things, specially because these when I get to it things can (will) be avoided as much as possible ;-) -- 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 DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Tue, 8 May 2007 14:42:37 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: I want to know how difficult would be to implement support for clip using gradient objects. Motivation to do so is to have clip border as fade out instead of hard cut. We need it for our software, Canola, but talking to Freevo guys show the same problem. I've already talked to raster about this issue and he suggested creating an overlay image with a copy of the background with alpha channel changed, but then comes the question raised by Tackaberry (freevo dev) if the background changes a lot, it couldn't be just one image, but the rendered background so far. How does it behave to retrieve rendered scene in different backends, like GL? We are willing to implement it if you give us some hints :-) it's not as easy as it sounds. what you want is generic clipping to an mask. that has been on the will do it one day list for a long time. so RFC-wise - absolutely. but implementing it so its vaguely efficient will need some work. any mask needs to be rendered first, THEN used when compositing objects. right now evas has no clip buffer mode (all objects clipped are clipped WHEN they are rendered, instead of being rendered to a temporary buffer first, then clipped when finally composited to the screen). for now its clip when you draw method is ok for most uses, but we still need it implemented. to implement this we will need (imho) the tile cache i suggested. something that lets you generate a surface from sources and cache just regions of it (tiles) that are needed. this means you don't re-generate it for every object clipped to it that needs a draw, but will allow us to cap the memory usage of such regions during a draw. but before leaping into this - note, this is not so simple as it needs implementing across multiple engines and graphics api's. -- 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 DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On Tue, 08 May 2007 15:28:16 -0400 Jason Tackaberry [EMAIL PROTECTED] babbled: On 2007-05-08 13:42, Gustavo Sverzut Barbieri wrote: Motivation to do so is to have clip border as fade out instead of hard cut. We need it for our software, Canola, but talking to Freevo guys show the same problem. This is definitely a big deal for us (Freevo). We've been resorting to ugly hacks to get this effect in text (i.e. using Imlib2 to render the text to an evas image object and fiddling with the alpha channel after), but other hacks are increasingly impractical for use-cases that involve fading across multiple objects. So I'm interested in hearing any advice from those who grok evas's core (of which I am not even remotely one). the advice is i would like this and it would be good but its not trivial to do right/well and right now i really don't have the time to do it - thus it's one of those backburner when i get to it things. Off topic now, but some other shortcomings that are an issue for us: 1. Lack of 3D transformations (on 2D objects). Gustavo has said he has a proposal for adding this, which is very nice to hear. actually - he wants 2d transforms (rotate, shear, scale, translate). but you can do enough with 2d. 2. GL engine a second class citizen. I sometimes read on e-devel about how this or that isn't working properly in the GL engine. At some point configure was updated to no longer build it by default. I'm afraid one day I'll do a svn update and discover raster has removed it because it was half working and nobody cared about it. [I care! :)] yes - it is 2n'd class - but it won't be removed. did you notice i added yuv-rgb fragment shader accel to the engine recently? it isn't dead - its just not a primary devel path. 3. Lack of subpixel precision. Makes stuff like the Ken Burns Effect impossible (or possible, but lame). However this is probably not practical without a big evas rewrite. I did just have the idea that we could get halfpel by creating a canvas size twice the display resolution and set the viewport to the display resolution -- but that option won't work since viewport feature was removed. Other options require buffer canvas hacks. it never would have worked even with the viewport before as evas just converted it to a 1:1 buffer. this is actually quite possible to be done - and in fact fairly easy - at least for the software engines. BUT its expensive as evas will need to render 4x or more the data. also co-ordinates are integer and converted to output co-ord space which is assumed to be 1:1 with canvas space. the engine api assumes 1:1 so i simply percolated that up to the evas api not as a hard requirement, but as a soft-requirement. api is still in theory capable of doing the large canvas-space viewport, but the expense of writing to such a canvas will be very high. you want half-pel then you will pay 4x the price of rendering. Anyway, thought I'd just mention this stuff so they're in the right people's minds. :) Jason. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Jason wrote: 2. GL engine a second class citizen. I sometimes read on e-devel about how this or that isn't working properly in the GL engine. At some point configure was updated to no longer build it by default. I'm afraid one day I'll do a svn update and discover raster has removed it because it was half working and nobody cared about it. [I care! :)] I care too (somewhat), and so does raster, and simon, and others... I have no experience with gl though, and would have to take time out to learn the api and its use, which I just don't have at the moment. Simon has wanted to rewrite the gl engine, maybe he can do something there if he finds the time. One thing that engine needs is some code for 'rendering to a texture', as this will be needed for various things. Another engine that needs work is... dfb. It could use some cleaning up. :) But above all, what is needed at the engines level is the introduction of 'objects' there, similar to what the canvas level has (not that the canvas itself couldn't use improvements, especially with smart objects). This is needed for most of the things that you and others want to have -- once that's done, it'll be much, much easier to extend the lib's capabilities. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] RFC gradient clip
I want to know how difficult would be to implement support for clip using gradient objects. Motivation to do so is to have clip border as fade out instead of hard cut. We need it for our software, Canola, but talking to Freevo guys show the same problem. I've already talked to raster about this issue and he suggested creating an overlay image with a copy of the background with alpha channel changed, but then comes the question raised by Tackaberry (freevo dev) if the background changes a lot, it couldn't be just one image, but the rendered background so far. How does it behave to retrieve rendered scene in different backends, like GL? We are willing to implement it if you give us some hints :-) -- 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 DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
On 2007-05-08 13:42, Gustavo Sverzut Barbieri wrote: Motivation to do so is to have clip border as fade out instead of hard cut. We need it for our software, Canola, but talking to Freevo guys show the same problem. This is definitely a big deal for us (Freevo). We've been resorting to ugly hacks to get this effect in text (i.e. using Imlib2 to render the text to an evas image object and fiddling with the alpha channel after), but other hacks are increasingly impractical for use-cases that involve fading across multiple objects. So I'm interested in hearing any advice from those who grok evas's core (of which I am not even remotely one). Off topic now, but some other shortcomings that are an issue for us: 1. Lack of 3D transformations (on 2D objects). Gustavo has said he has a proposal for adding this, which is very nice to hear. 2. GL engine a second class citizen. I sometimes read on e-devel about how this or that isn't working properly in the GL engine. At some point configure was updated to no longer build it by default. I'm afraid one day I'll do a svn update and discover raster has removed it because it was half working and nobody cared about it. [I care! :)] 3. Lack of subpixel precision. Makes stuff like the Ken Burns Effect impossible (or possible, but lame). However this is probably not practical without a big evas rewrite. I did just have the idea that we could get halfpel by creating a canvas size twice the display resolution and set the viewport to the display resolution -- but that option won't work since viewport feature was removed. Other options require buffer canvas hacks. Anyway, thought I'd just mention this stuff so they're in the right people's minds. :) Jason. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Jason wrote: This is definitely a big deal for us (Freevo). We've been resorting to ugly hacks to get this effect in text (i.e. using Imlib2 to render the text to an evas image object and fiddling with the alpha channel after), but other hacks are increasingly impractical for use-cases that involve fading across multiple objects. If you're using a buffer evas right now for this, then the best way is to add a suitable gradient object above (and covering) the objects you want to fade and set its render-op to MUL. This will 'fade' any objects under it. But see my subsequent email on this and your other points. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
