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
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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ 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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
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=100url=/
___
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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
