[E-devel] Emotion - problem with emotion_object_position_set
Hi all, I was working with emotion (gstreamer module) and when I tried to use emotion_object_position_set(obj, 0) it just doesn't work. My test case was having a file playing and trying to stop it, reseting its position to 0. It seems that when I try to do that it calls em_pos_set(video, pos=0), and when it checks if (video->seek_to_pos == pos) the function just returns. I think the problem is that the only place where seek_to_pos is updated is in this function, so if you try to set a file position to 0, it doesn't works because seek_to_pos is already 0 (even if the file is already playing a little while). Maybe this check is unnecessary... -- Rafael Antognolli ProFUSION embedded systems http://profusion.mobi - 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
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
[E-devel] 回复: [E-devel] entrance dual-screen fix
how can I add notebook with etk in e_config_dialog_new() widget? please give me a example thank you! 2008/8/27, Joel Klinghed <[EMAIL PROTECTED]>: > Hi. > > I have a dual screen system (using Nvidia:s xinerama emulation) with > screen 0 to the right of screen 1. > Entrance handles the screens nicely when moving the cursor between them > but initially it always start up as if it tries to center over both > screens but using screen 0 as origin (ie. half ends up outside the screen). > The problem was that the "ui" object was resized after the workspace > size in window_resize_cb, not the screen size (as in screen_switch_cb). > > Attached patch fixes this at least for me... > > /JK > -- wangxiangao - 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
