Re: [E-devel] RFC evas_object_transform()
On Sat, 19 May 2007 15:34:01 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Sat, 19 May 2007 09:35:25 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Sat, 12 May 2007 10:58:26 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Sat, 12 May 2007 07:14:04 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) that is a good question. what do borders mean then? i would say that borders remain unscaled at the bounds of the transformed quad (the quad being the bounds of the image post-transform). Actually, I think it would make more sense if the borders were applied before the transform. Imo, borders describe how the original texture should scale. If the texture is already transformed when borders are applied, it won't be easy/intuitive to predict the result. thats the result of what i was describing. the borders describe a final-output-pace inside from the edges of the texture not to scale. And it would allow to rotate a bordered-scaled-rectangle for example. If the borders were applied after the transform, the borders of the rectangle would look really weird. yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. 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 - 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 evas_object_transform()
On Sat, 19 May 2007 09:35:25 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Sat, 12 May 2007 10:58:26 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Sat, 12 May 2007 07:14:04 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) that is a good question. what do borders mean then? i would say that borders remain unscaled at the bounds of the transformed quad (the quad being the bounds of the image post-transform). Actually, I think it would make more sense if the borders were applied before the transform. Imo, borders describe how the original texture should scale. If the texture is already transformed when borders are applied, it won't be easy/intuitive to predict the result. And it would allow to rotate a bordered-scaled-rectangle for example. If the borders were applied after the transform, the borders of the rectangle would look really weird. yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. 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 - 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 - 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 evas_object_transform()
On Sat, 12 May 2007 07:14:04 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). doing transformed fills in gl is easy - you just need to work out the quad corner points and then draw 1 or more textured quads (probably using gl's clip to limit the draw). that doesn't obviate the need for render-to-texture :) yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. in simple cases it's possible - but not generically. if it happens to be a simple translation, or scale it's doable. rotation at the same time will make it hard- add in shearing and you are really going to have a hard time. 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 evas_object_transform()
On Sat, 12 May 2007 10:58:26 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Sat, 12 May 2007 07:14:04 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) that is a good question. what do borders mean then? i would say that borders remain unscaled at the bounds of the transformed quad (the quad being the bounds of the image post-transform). yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. 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 - 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 evas_object_transform()
On Sat, 12 May 2007 09:36:28 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Simon wrote: For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) Two different sets of 'transforms' are involved here: Simon wrote: For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) One would be those which apply to how the image-fill should behave, ie. border-scale the fill, then rotate/skew that, etc. So, you need to border-scale first to a buffer and then apply any further trans (ie. any rotation/skewing/whatever) to *that* buffer result (and repeat/reflect/restrict as need be). That is basically independent of any engine particulars -- We need to fill-scale to a buffer first in order for the 'pieces' of the image to fit together accurately and without 'seams' when further tansformed and composited. The only way to avoid doing this is if the rendering engine has the ability to deal with the 9 abutting pieces as a 'whole', so that no edges get sampled/composited twice. It's possible that gl may be able to do that via meshes. yes - poly meshes will do this. :) you just need to calculate the 3x3 grid of meshes and how to transform the key points in it. thats a matter of figuring out policy - where does border kick in in the transform world? i would suggest it kicks in POST transform of the bounding quad - the border insets are done in post-transform space as calculated insets. maybe we need to also consider simplifying this. border scaling is only valid for aligned and scaled images. if a transform matrix is applied, it is applied post scale with borders. The second set of transforms would be as applies to the obj as a whole, and there what one actually does depends on what the engines have available as being easiest.. But the semantics would be that the result is that the object as a whole is transformed, after the filling transforms are done. yes - i am beginning to think if we add a transform matrix option - border scaling is done before transform. this means you simply need to take the 3x3 mesh and transform the points with the matrix - then draw the mesh. current fill settings will apply BEFORE the transform (as well as border scaling) If you think of an image object as a rectangle which has been filled with a pattern (in vgfx terminology.. or textured as I prefer to call it), then transforms to the image object (as opposed to the fill, ie. the pattern), are the same as transforming the patterned rectangle. :) 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 evas_object_transform()
Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. 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 evas_object_transform()
On Sat, 12 May 2007 07:14:04 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. 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 - 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 evas_object_transform()
Simon wrote: For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) Two different sets of 'transforms' are involved here: Simon wrote: For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) One would be those which apply to how the image-fill should behave, ie. border-scale the fill, then rotate/skew that, etc. So, you need to border-scale first to a buffer and then apply any further trans (ie. any rotation/skewing/whatever) to *that* buffer result (and repeat/reflect/restrict as need be). That is basically independent of any engine particulars -- We need to fill-scale to a buffer first in order for the 'pieces' of the image to fit together accurately and without 'seams' when further tansformed and composited. The only way to avoid doing this is if the rendering engine has the ability to deal with the 9 abutting pieces as a 'whole', so that no edges get sampled/composited twice. It's possible that gl may be able to do that via meshes. The second set of transforms would be as applies to the obj as a whole, and there what one actually does depends on what the engines have available as being easiest.. But the semantics would be that the result is that the object as a whole is transformed, after the filling transforms are done. If you think of an image object as a rectangle which has been filled with a pattern (in vgfx terminology.. or textured as I prefer to call it), then transforms to the image object (as opposed to the fill, ie. the pattern), are the same as transforming the patterned rectangle. :) 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 evas_object_transform()
On Tue, 8 May 2007 16:37:35 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: As Jason Tackaberry said on the other thread, here comes my proposal for 3d transformation for 2d objects. I've discussed this with raster at bossa conference. My proposal was born to solve the missing rotate, that if solved would still raise missing shear, etc.. Raster said he don't have a _rotate() method yet because he couldn't get it as fast as possible on each engine. Since many operations can be handled by transform matrix and some engines (ie: GL), can handle it fast, just expose: void evas_object_transform(Evas_Object *obj, double matrix[4][4]) Given one knows how to fill the coefficients he can achieve his rotation/shear/... goals and it will be fast as hell on GL. Other engines will not run as fast, but it'll be up to the user to handle that. This would enable fancy beryl-like effects inside Evas, wanted by Freevo guys. This may also be used by embedded devices given OpenGL/ES support. this is perfectly possible and on the list of things i'd like to see evas get (eventually) but again like most things. it gets expensive to do AND keep high-quality AND high-speed. rotation is a subset of transform matrix fun and probably the most common use of them after scaling. the only other things we would miss is shearing. a transform makes it very generic - but transform matricies generally tend to be much more painful to work with than simple rotate/scale calls. i'd personally like to have both. use the matrix OR just use the resize/fill/(and later rotate) calls. -- 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 evas_object_transform()
On Wed, 9 May 2007 00:51:14 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: [things about transforms and such] Most of this, and clipping (and some other things), are coming hopefully within this month or so. But there are things you should be aware of. Generally speaking, it's not too difficult to do any of these things - especially if one is willing to forgo some quality and/or some speed.. but even then, getting this in evas requires a fairly large rewrite of the engine level internals. indeed - i have a non-trivial queue of mails from you all on this topic! :) In evas however we have further things to deal with, especially when it comes to image objects and 'transforms'. A 'fast' software implementation for rotations is really not an issue. Image objects in evas have these 'border' attributes which actually make them into a compound, structured object.. not just a simple image in the sense that most libs deal with. Also, we want fairly 'high quality' software down-scaling, which again most libs bypass by using eg. bilinear interpolation (which gives a 'decent' means for implementing tarnsforms). you missed the fact that a transformed object now is no longer an aligned rectangle - so the event engine needs a big change to handle mouse move, in and out events etc. :) we need to now handle transformed regions for objects - or do we? do we just expand the event rect to be the bounds of the whole object? what about clipping. right now clips also clip the event area. personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. These two aspects together make for something more complex than what is found in most other libs that deal with 'images' and 'transforms'. One should realize that in order to satisfy these, setting a transform on an image object is going to mean apply the trans to the result of the image obj's fill. Only sometimes will we be able to compose the transform with the fill scaling and do it all in a single pass. It doesn't matter what the 'rendering' engine, ie. wether it's software or xrender or gl or whatever.. this will always come up with scaling+borders. aye. borders also complicate things a lot. Applying transforms to objects like rects and gradients is simpler (I'll refrain from mentioning styled text objs or textblock objs), but for compound objects like smart-objs one needs to make some decisions. text and textblock objects likely will need to be pre-rendered to a buffer then have that buffer transformed. :( One can apply the transform to each member obj of the smart object.. and things may end up not 'lining-up' as desired. Or one can apply the trans to the result of rendering the untransformed smart object.. and then there will be its own set of 'issues'. [NB: One can't, in general, decompose a transform into a simple rotation plus scaling plus a simple shearing -- you can at best get something like a scaling plus a generalized rotation where you rotate each of the two axis differently.. and this is just for non-projective transforms.] yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). The notion of a transformable interface is something that I think has been too quickly hyped and is going to be rather tricky to actually achieve -- if one wants good-looking results and an un-ambiguous semantics.. I don't think the SVG 'spec' alone will give that. 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 evas_object_transform()
On 5/8/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: [...] Since many operations can be handled by transform matrix and some engines (ie: GL), can handle it fast, just expose: void evas_object_transform(Evas_Object *obj, double matrix[4][4]) rephorm noted on IRC that it's 3x3 matrix for 2d objects :-) -- 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 evas_object_transform()
[things about transforms and such] Most of this, and clipping (and some other things), are coming hopefully within this month or so. But there are things you should be aware of. Generally speaking, it's not too difficult to do any of these things - especially if one is willing to forgo some quality and/or some speed.. but even then, getting this in evas requires a fairly large rewrite of the engine level internals. In evas however we have further things to deal with, especially when it comes to image objects and 'transforms'. A 'fast' software implementation for rotations is really not an issue. Image objects in evas have these 'border' attributes which actually make them into a compound, structured object.. not just a simple image in the sense that most libs deal with. Also, we want fairly 'high quality' software down-scaling, which again most libs bypass by using eg. bilinear interpolation (which gives a 'decent' means for implementing tarnsforms). These two aspects together make for something more complex than what is found in most other libs that deal with 'images' and 'transforms'. One should realize that in order to satisfy these, setting a transform on an image object is going to mean apply the trans to the result of the image obj's fill. Only sometimes will we be able to compose the transform with the fill scaling and do it all in a single pass. It doesn't matter what the 'rendering' engine, ie. wether it's software or xrender or gl or whatever.. this will always come up with scaling+borders. Applying transforms to objects like rects and gradients is simpler (I'll refrain from mentioning styled text objs or textblock objs), but for compound objects like smart-objs one needs to make some decisions. One can apply the transform to each member obj of the smart object.. and things may end up not 'lining-up' as desired. Or one can apply the trans to the result of rendering the untransformed smart object.. and then there will be its own set of 'issues'. [NB: One can't, in general, decompose a transform into a simple rotation plus scaling plus a simple shearing -- you can at best get something like a scaling plus a generalized rotation where you rotate each of the two axis differently.. and this is just for non-projective transforms.] The notion of a transformable interface is something that I think has been too quickly hyped and is going to be rather tricky to actually achieve -- if one wants good-looking results and an un-ambiguous semantics.. I don't think the SVG 'spec' alone will give that. 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
