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
