Re: [E-devel] Gradients are gone
Dmitriy wrote: >> ... >> >>This is great opportunity for those who are evas engineers to start >> thinking/ >> working on 'native' implementations for their engine of interest -- I can't >> do >> *all* engines in x amount of time.. and while a simple mechanism to >> implicitly >> 'fall-back' to software easily would be nice, that's not quite available >> right >> now and in any case the point of much of this is to have as 'native' versions >> of things as much as possible. >> >> ... >> > > Hello, Jose! > > It's about new Direct3D Evas engine for Win32, that I've developed for > Enlightenment during SoC. For now it is not yet committed to the main code > repository, but I am able to support gradient functionality that you need in > it. I suppose it is necessary to implement all of the eng_gradient2_* > functions. Please contact me and CC Vincent Torri <[EMAIL PROTECTED]> with > details. > > The way of implementation of gradients in this engine is not difficult, we > can use pixel shaders capabilities easily. For each gradient type we can make > own pixel shader, for example: > > Linear gradient shader: > > // Input register data > float4 f4StartPoint : register(c0); // xy in [0; 1] x [0; 1] > float4 f4Direction : register(c1); // xy - normalized, w - length > float4 f4StartColor : register(c2); // rgba > float4 f4EndColor : register(c3); // rgba > > float4 main(float2 uv: TEXCOORD0) : COLOR0 > { >float2 pos = uv - f4StartPoint.xy; >// saturate - clamp input value in [0; 1] >float f = saturate(dot(pos, f4Direction.xy) / f4Direction.w); >return lerp(f4StartColor, f4EndColor, f); > } > > And then just set proper constants when drawing the object. > This would be the most 'native' version for the engine:). > Excellent. That's exactly the kind of thing one wants with this. Note that for linear grad2, where the fill geometry is given by specifying the start and end points (rel to the obj's coord system with origin at its top-left), the fill-transform is simply used to get new start/end points from the given ones. Though of course one must use the *inverse* of the supplied transform matrix, and we only use the affine part. For radial grads it's a bit less intuitive, but basically, whatever method you'd be using to draw an untransformed radial grad2, simply use the fill-transform to transform back to an untransformed coordinate system and draw your un-transf radial grad rel to that. More or less anyway.. so long as you'd be doing your linear interpolation of color stops in non-premul color space that would work fine. There's also the 'spread' modes to deal with: repeat, reflect, restrict (aka none), and pad. Evas has a couple more right now but they'll go away. Now, here's an experiment everyone can try. Forget about the software implementation I gave for say the new linear grad2 evas object -- assume it hasn't been done at all, and all you have is the api to work from plus some of the canvas level funcs I wrote. Assume further that your engine of interest is the only one that exists. Then try and write an implementation of this new linear grad2 evas object all the way from the canvas down to the engine (only one engine for you). Basically, it's just you trying to implement it with your engine alone. See what you come with and we can compare notes after a bit. :) Click here for financial aid options. Quick and Easy. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oIGkZ6rYS7gfwKssFFZBSjXWRTkIfxOzAQwc31QdNt3DYnU/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gradients are gone
Jose Gonzalez wrote: > ... > >This is great opportunity for those who are evas engineers to start > thinking/ > working on 'native' implementations for their engine of interest -- I can't do > *all* engines in x amount of time.. and while a simple mechanism to implicitly > 'fall-back' to software easily would be nice, that's not quite available right > now and in any case the point of much of this is to have as 'native' versions > of things as much as possible. > > ... Hello, Jose! It's about new Direct3D Evas engine for Win32, that I've developed for Enlightenment during SoC. For now it is not yet committed to the main code repository, but I am able to support gradient functionality that you need in it. I suppose it is necessary to implement all of the eng_gradient2_* functions. Please contact me and CC Vincent Torri <[EMAIL PROTECTED]> with details. The way of implementation of gradients in this engine is not difficult, we can use pixel shaders capabilities easily. For each gradient type we can make own pixel shader, for example: Linear gradient shader: // Input register data float4 f4StartPoint : register(c0); // xy in [0; 1] x [0; 1] float4 f4Direction : register(c1); // xy - normalized, w - length float4 f4StartColor : register(c2); // rgba float4 f4EndColor : register(c3); // rgba float4 main(float2 uv: TEXCOORD0) : COLOR0 { float2 pos = uv - f4StartPoint.xy; // saturate - clamp input value in [0; 1] float f = saturate(dot(pos, f4Direction.xy) / f4Direction.w); return lerp(f4StartColor, f4EndColor, f); } And then just set proper constants when drawing the object. This would be the most 'native' version for the engine:). Best regards, Dzmitry Mazouka - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gradients are gone.
Vincent wrote: > ... >> >> Any comments, suggestions, or help with implementing things for >> the various >> engines, are highly welcome. > > I've already talked about that with my student who works on the > Direct3D engine, and he says that using the pixels shaders for that > engine is not really difficult. I'll tell him to participate to the > discussion > That would be great! It should also be possible to do with gl as well. :) Get educated. Click here for Adult Education programs. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNbXUTnFmfQsnDglXXoPvCDJZQKPFCMWUtwuluPG9XbVHbh/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gradients are gone.
Gustavo wrote: > On Thu, Aug 28, 2008 at 9:01 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >> The patch contains some further improvements on the new grads, and the >> start >> of some new things to come for evas, so let me briefly go over some of them >> here. >> >> 1. The start of adding 'fill-transforms' and 'fill-spread' modes to evas >> image >> objects. I've added the api and implemented the basic canvas level stuff. >> Here >> are the api functions for that (set ones only here), just like the grad2 >> ones: >> >> EAPI void evas_object_image_fill_transform_set(Evas_Object *obj, >> Evas_Transform *t); >> EAPI void evas_object_image_fill_spread_set(Evas_Object *obj, int >> tile_mode); >> > > before going on, we need to always check performance to see if no bad > performance entered svn. > > Image objs won't be affected by any new 'tarnsform' stuff -- if one doens't use them (ie. identity transform), they'll be as fast or a bit faster (after I have a chance to do some further stuuf) then they are now. Grad2's are even faster -- linear grads are in most cases around 3 times faster than the current ones (not including the horz or vert special ones which are vey, very fast) >> The semantics of the fill-transform is simple: First, border-scale the >> image >> to the current fill size, then apply the combined transform of the current >> fill- >> transform and the translation to the current fill origin, where the >> translation >> to the fill origin is done first (note though that transforms are really >> used >> as the inverse transformations of what one wants, so the given fill >> translation >> is composed on the left with the given fill-transform). All fill-transforms >> are >> taken relative to the image object's top-left as the coordinate system >> origin, >> of course. >> > > what you mean with border scale? I hope it's about current border > property of Evas, remember that we do need to keep these, also things > like border_center_fill, if we add those. > > Yes, it means that if borders are present one should make sure that the semantics includes that first the image is scaled to the fill size, preserving borders, and then the fill transform applied. :) >> This is great opportunity for those who are evas engineers to start >> thinking/ >> working on 'native' implementations for their engine of interest -- I can't >> do >> *all* engines in x amount of time.. and while a simple mechanism to >> implicitly >> 'fall-back' to software easily would be nice, that's not quite available >> right >> now and in any case the point of much of this is to have as 'native' >> versions >> of things as much as possible. >> > > /me looks at common_16 and cries... > > > I tried to warn you about this when you first started down that path... :) But no matter, those engines need to be redone. >> 2. I've also added some api functions for working with transforms.. these >> will >> grow over time, but the given ones are all that's likely needed right now. >> They are: >> >> EAPI void evas_transform_identity_set(Evas_Transform *t); >> EAPI void evas_transform_rotate(double angle, Evas_Transform *t); >> EAPI void evas_transform_translate(float dx, float dy, Evas_Transform *t); >> EAPI void evas_transform_scale(float sx, float sy, Evas_Transform *t); >> EAPI void evas_transform_shear(float sh, float sv, Evas_Transform *t); >> EAPI void evas_transform_compose(Evas_Transform *l, Evas_Transform *t); >> > > It's better to keep Evas_Transform as the first parameter, making it > an OO-like API. > OK. :) Get the shot you need with a discreet new spy camera. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m1EqgelscckxShwExQWdgSx8eYSg3Mfau00oOPoWe3BcPk4/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gradients are gone.
On Thu, Aug 28, 2008 at 9:01 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > The patch contains some further improvements on the new grads, and the > start > of some new things to come for evas, so let me briefly go over some of them > here. > > 1. The start of adding 'fill-transforms' and 'fill-spread' modes to evas > image > objects. I've added the api and implemented the basic canvas level stuff. > Here > are the api functions for that (set ones only here), just like the grad2 > ones: > > EAPI void evas_object_image_fill_transform_set(Evas_Object *obj, > Evas_Transform *t); > EAPI void evas_object_image_fill_spread_set(Evas_Object *obj, int > tile_mode); before going on, we need to always check performance to see if no bad performance entered svn. > The semantics of the fill-transform is simple: First, border-scale the > image > to the current fill size, then apply the combined transform of the current > fill- > transform and the translation to the current fill origin, where the > translation > to the fill origin is done first (note though that transforms are really > used > as the inverse transformations of what one wants, so the given fill > translation > is composed on the left with the given fill-transform). All fill-transforms > are > taken relative to the image object's top-left as the coordinate system > origin, > of course. what you mean with border scale? I hope it's about current border property of Evas, remember that we do need to keep these, also things like border_center_fill, if we add those. > This is great opportunity for those who are evas engineers to start > thinking/ > working on 'native' implementations for their engine of interest -- I can't > do > *all* engines in x amount of time.. and while a simple mechanism to > implicitly > 'fall-back' to software easily would be nice, that's not quite available > right > now and in any case the point of much of this is to have as 'native' > versions > of things as much as possible. /me looks at common_16 and cries... > 2. I've also added some api functions for working with transforms.. these > will > grow over time, but the given ones are all that's likely needed right now. > They are: > > EAPI void evas_transform_identity_set(Evas_Transform *t); > EAPI void evas_transform_rotate(double angle, Evas_Transform *t); > EAPI void evas_transform_translate(float dx, float dy, Evas_Transform *t); > EAPI void evas_transform_scale(float sx, float sy, Evas_Transform *t); > EAPI void evas_transform_shear(float sh, float sv, Evas_Transform *t); > EAPI void evas_transform_compose(Evas_Transform *l, Evas_Transform *t); It's better to keep Evas_Transform as the first parameter, making it an OO-like API. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gradients are gone.
On Thu, 28 Aug 2008, Jose Gonzalez wrote: > Toma wrote: > >> I think the most recent patches for gradients have totally destroyed >> all gradients in E. Poor lil Edjy is ruined and so is the Gradient >> wallpaper selector and all the things associated with that. >> >> > Attached (I hope) is a patch to fix those 'old' grads.. they should be > back, > for now. :) > > The patch contains some further improvements on the new grads, and the > start > of some new things to come for evas, so let me briefly go over some of them > here. > > 1. The start of adding 'fill-transforms' and 'fill-spread' modes to evas > image > objects. I've added the api and implemented the basic canvas level stuff. > Here > are the api functions for that (set ones only here), just like the grad2 > ones: > > EAPI void evas_object_image_fill_transform_set(Evas_Object *obj, > Evas_Transform *t); > EAPI void evas_object_image_fill_spread_set(Evas_Object *obj, int tile_mode); > > Hopefully by sometime next week I'll have a chance to finish off the > software > engines implementation of this. > > The semantics of the fill-transform is simple: First, border-scale the > image > to the current fill size, then apply the combined transform of the current > fill- > transform and the translation to the current fill origin, where the > translation > to the fill origin is done first (note though that transforms are really used > as the inverse transformations of what one wants, so the given fill > translation > is composed on the left with the given fill-transform). All fill-transforms > are > taken relative to the image object's top-left as the coordinate system > origin, > of course. > > Shortly after this is done, I'll add the basics of stroke/fill texturing of > 'shape' objects with images and grad2s. Again, as before, I'll do a sample > software implementation for (rounded) rects and for lines (with caps). > > This is great opportunity for those who are evas engineers to start > thinking/ > working on 'native' implementations for their engine of interest -- I can't > do > *all* engines in x amount of time.. and while a simple mechanism to > implicitly > 'fall-back' to software easily would be nice, that's not quite available > right > now and in any case the point of much of this is to have as 'native' versions > of things as much as possible. > > > 2. I've also added some api functions for working with transforms.. these > will > grow over time, but the given ones are all that's likely needed right now. > They are: > > EAPI void evas_transform_identity_set(Evas_Transform *t); > EAPI void evas_transform_rotate(double angle, Evas_Transform *t); > EAPI void evas_transform_translate(float dx, float dy, Evas_Transform *t); > EAPI void evas_transform_scale(float sx, float sy, Evas_Transform *t); > EAPI void evas_transform_shear(float sh, float sv, Evas_Transform *t); > EAPI void evas_transform_compose(Evas_Transform *l, Evas_Transform *t); > > The semantics for these is described in comments above their declaration in > Evas.h, but basically (except for the first one which sets a transform to the > identity one), they *left-multiply* the given transform t by a suitable > transform > obtained from the input data (eg. by a translation by some dx,dy, or by a > rotation > by some angle, etc). These are implemented in a new "evas_transform.c" file > which > I've attached, and is to go into the evas 'canvas' dir (added to Makefile.am > there). > > Any comments, suggestions, or help with implementing things for the > various > engines, are highly welcome. I've already talked about that with my student who works on the Direct3D engine, and he says that using the pixels shaders for that engine is not really difficult. I'll tell him to participate to the discussion Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gradients are gone.
Toma wrote: I think the most recent patches for gradients have totally destroyed all gradients in E. Poor lil Edjy is ruined and so is the Gradient wallpaper selector and all the things associated with that. Attached (I hope) is a patch to fix those 'old' grads.. they should be back, for now. :) The patch contains some further improvements on the new grads, and the start of some new things to come for evas, so let me briefly go over some of them here. 1. The start of adding 'fill-transforms' and 'fill-spread' modes to evas image objects. I've added the api and implemented the basic canvas level stuff. Here are the api functions for that (set ones only here), just like the grad2 ones: EAPI void evas_object_image_fill_transform_set(Evas_Object *obj, Evas_Transform *t); EAPI void evas_object_image_fill_spread_set(Evas_Object *obj, int tile_mode); Hopefully by sometime next week I'll have a chance to finish off the software engines implementation of this. The semantics of the fill-transform is simple: First, border-scale the image to the current fill size, then apply the combined transform of the current fill- transform and the translation to the current fill origin, where the translation to the fill origin is done first (note though that transforms are really used as the inverse transformations of what one wants, so the given fill translation is composed on the left with the given fill-transform). All fill-transforms are taken relative to the image object's top-left as the coordinate system origin, of course. Shortly after this is done, I'll add the basics of stroke/fill texturing of 'shape' objects with images and grad2s. Again, as before, I'll do a sample software implementation for (rounded) rects and for lines (with caps). This is great opportunity for those who are evas engineers to start thinking/ working on 'native' implementations for their engine of interest -- I can't do *all* engines in x amount of time.. and while a simple mechanism to implicitly 'fall-back' to software easily would be nice, that's not quite available right now and in any case the point of much of this is to have as 'native' versions of things as much as possible. 2. I've also added some api functions for working with transforms.. these will grow over time, but the given ones are all that's likely needed right now. They are: EAPI void evas_transform_identity_set(Evas_Transform *t); EAPI void evas_transform_rotate(double angle, Evas_Transform *t); EAPI void evas_transform_translate(float dx, float dy, Evas_Transform *t); EAPI void evas_transform_scale(float sx, float sy, Evas_Transform *t); EAPI void evas_transform_shear(float sh, float sv, Evas_Transform *t); EAPI void evas_transform_compose(Evas_Transform *l, Evas_Transform *t); The semantics for these is described in comments above their declaration in Evas.h, but basically (except for the first one which sets a transform to the identity one), they *left-multiply* the given transform t by a suitable transform obtained from the input data (eg. by a translation by some dx,dy, or by a rotation by some angle, etc). These are implemented in a new "evas_transform.c" file which I've attached, and is to go into the evas 'canvas' dir (added to Makefile.am there). Any comments, suggestions, or help with implementing things for the various engines, are highly welcome. Get educated. Click here for Adult Education programs. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNbXdry8jLkUb84w1HNK75GcE4zYVfvya4wTPHD5bg1ZgKE/Index: evas/src/lib/include/evas_private.h === --- evas/src/lib/include/evas_private.h (revision 35699) +++ evas/src/lib/include/evas_private.h (working copy) @@ -489,7 +489,8 @@ void (*render_pre) (Evas_Object *obj); void (*render_post) (Evas_Object *obj); - int (*visual_id_get) (Evas_Object *obj); + unsigned int (*type_id_get) (Evas_Object *obj); + unsigned int (*visual_id_get) (Evas_Object *obj); void *(*engine_data_get) (Evas_Object *obj); void (*store) (Evas_Object *obj); Index: evas/src/lib/Evas.h === --- evas/src/lib/Evas.h (revision 35699) +++ evas/src/lib/Evas.h (working copy) @@ -500,6 +500,10 @@ EAPI Evas_Bool evas_object_image_border_center_fill_get(const Evas_Object *obj); EAPI void evas_object_image_fill_set(Evas_Object *obj, Evas_Coord x, Evas_Coord y, Evas_Coord w, Evas_Coord h); EAPI void evas_object_image_fill_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord *y, Evas_Coord *w, Evas_Coord *h); + EAPI void evas_object_image_fill_spread_set (Evas_Object *obj, int tile_mode); + EAPI int evas_object_image_fill_spread_get (const Evas_Object *obj); + EAPI void evas_object_image_fill_tra
Re: [E-devel] Gradients are gone.
Carsten wrote: > On Wed, 27 Aug 2008 21:21:33 +0800 Toma <[EMAIL PROTECTED]> babbled: > > >> I think the most recent patches for gradients have totally destroyed >> all gradients in E. Poor lil Edjy is ruined and so is the Gradient >> wallpaper selector and all the things associated with that. >> > > i saw today. what is bizarre - i looked at the patches and they added a new > gradient2 object - and didnt remove the old gradient... so it should thave > been > non-invasive... hmmm. > I added some new obj funcs but neglected to update those for the current grad objs. Obviously an unsconcious desire to kill the old ones off. :) I'll send a patch soon to fix that and a few other minor bits. Click to become a master chef, own a restaurant and make millions. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m4pC81n7PdKjuRI9l8rLw7CRxR5Di4wBDsH1L8Fm8fGxFAw/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gradients are gone.
On Wed, 27 Aug 2008 21:21:33 +0800 Toma <[EMAIL PROTECTED]> babbled: > I think the most recent patches for gradients have totally destroyed > all gradients in E. Poor lil Edjy is ruined and so is the Gradient > wallpaper selector and all the things associated with that. i saw today. what is bizarre - i looked at the patches and they added a new gradient2 object - and didnt remove the old gradient... so it should thave been non-invasive... hmmm. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Gradients are gone.
I think the most recent patches for gradients have totally destroyed all gradients in E. Poor lil Edjy is ruined and so is the Gradient wallpaper selector and all the things associated with that. Toma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel