> > > so you can define gradients for a bg - but store the saved
> > > config in a .edj file. use an imag with a pre-rendered
> > > alpha->white gradient (horz, vert, radial) then use a bg rect
> > > for one color and set the color of the gradient image object
> > > to determine the 2nd color for the gradient - and then just
> > > properties (scale, tile, which image, where and the 2 colors).
> > > a quick way for users to get a gradient bg that they can share
> > > with friends, other computers etc. just like images in .edj
> > > files. identical mechanism.
Ahhhhhh... I see. A simple bg creation tool.
Ummmmm... maybe create an evas buffer-engine canvas, fill
it with a rect of one col, load the image and set a mult color as
the other col, then use the blend-op to render the image obj to
the rect... save the result canvas data to an edj via another image
obj... Something like that you had in mind?
But wouldn't this be better left to a more capable, and
potentially more powerful, e17-background-creation app?
> >
> > Wouldn't it more sense to add evas gradient support to edje?
>
> sure - except 3 things
> 1. need to dd the code to edje
> 2. gradients are slower than image manipulation - especially in non-
> software engines
> 3. you need a gui to select attributes for your gradient anyway so
> this need still stands - it simply would implement it using
> manipulated images recoloured in edje :)
>
> were gradients supported in edje then 3. could use it as a saving
> mechanism - but you still may hit performance issues with 2.
> remember gradients re one of the least used and least optimised
> bits of evas - admittedly using them will force them to be
> optimized but i'd hoped to put that off so we wouldn't need to do
> it before e17 :)
Well, what you described is a kind of gradient-like image
creation mechanism whose results really aren't capable of being
exactly duplicated simply with the gradient api alone..
But grads in edje would be great to have in any case, and I'd
hoped to get to add these.. eventually..... but never got a chance
to get beyond some basic notes on paper and some emails to you :)
There's always more that could be done to speed-up gradient
rendering for any engine.. Grad performance for the xrender engine
needs improving (eg. not rendering the whole thing every time), etc.
But it's not really that bad (well, if you want sinusoidal or angular
grads and such.. things aren't going to be lightning fast, no matter
what the engine).
> then again we do need to do a major overhaul of evas engine
> internals - at lest colorspace and engine api... :(
>
Somebody was working on this, nearly done with some parts
I'm told.. But I hear he got busy with some other stuff recently
and may not be able to get back to it til the weekend.
There's engine api rewriting to be done (object-specific
contexts to be setup), along with redoing the image rendering
pipeline (including rewriting the scaling functions), along with
writing the various render ops for the xrender engine, along with
adding image and general object rotation, along with the start of
some basic "vgfx" stuff like thick lines with styled endcaps and
rounded-rects with styled corners (stroked-and/or-filled), along
with some other things...
> > E.g. something like:
> >
> > collections {
> > group {
> > name: "grad_test";
> > parts {
> > part {
> > name: "grad";
> > type: GRADIENT;
> > description {
> > gradient {
> > angle: 90;
> > spread: 1;
> > color: 255 255 255 255 0; // r g b a distance
> > color: 0 0 0 0 1;
> > }
> > }
> > }
> > }
> > }
> > }
> >
> > which would result in something like:
> >
> > http://rephorm.com/files/dump/edje_grad.png
> >
> > (actual screenshot)
> >
> > I still have a bit more to add and test, but looks fairly
> > straightforward. The only question would be how to transition
> > between states on a GRADIENT part. Do we actually try to
> > calculate a transition gradient? This would be straightforward
> > if the control points were at the same distances. For others,
> > it gets more complex (would need get the union of control point
> > locations for both sides, and then interpolate from there).
> > Shouldn't be unreasonable though.
>
> well indeed - nice, grad objs.
Oh wow! It sure is well done indeed :)
> need to do more than linear tho... and then how to specify all
> the params of other gradient types... anyway.
>
Well, one can start by just having no params, ie. use the
defaults that come with each given type. I really didn't want to
have the (type,params) api, but I wanted extensible grad capabilities
without 200 new api functions... The ideal would've been loadable
obj types, each with its own header file (like evas engines) that
would expose a particular obj's api in there... anyway. :)
> for tweening transitions. this is tough. if start and end gradients
> dont have the same control points (number, position) what do you do?
> do you try and merge control points? or do you do a merged overlay
> of all control points so the intermediat grad is a superset of all
> control points (exact duplicates removed) and then just linear
> interp the colors of these control points (and calculate their rgba
> from their appropriate positions in the start and end grdients).
> i would say that is what you want... :)
>
Ummmmm... depends what you guys mean by 'tweening transitions',
sounds like what you're thinking about is script-driven transitions
between grad states.. See below :)
Brian: You've gone farther with this then I imagined anyone
was ever going to get to, so I'll give you what I'd thought about
doing (one day) for "edje grad objs" -- for what it's worth :)
First, I would put the 'angle' and 'spread' properties
under the general 'fill' tag. This is because that's really where
they belong logically (describes various aspects of the way the
filling of the object region is done), and also because image
objects are going to get these very same properties as well
(ie. image objects will get an angle and spread mode).
Now, as far as the gradient description goes..
I would not put the color stops inside the gradient tag,
even though this seems like the natural thing to do.
Here's why: A spectrum is the basic building block of a
gradient.. and by 'spectrum' here I mean an abstract mapping
s:[0,1] --> ColorSpace (and lets ignore for now issues of premul
or not, or hsv vs rgb, etc). Note that many different sets of stops
can generate the same spectrum.
Such a spectrum gives one-dim texture data, and it's the
grad equivalent of two-dim texture data for image objs.
One would really want to be able to re-use spectrums, load
and share them for various grad objs, etc..
To that end, I've added the ability to set a file on an
evas grad obj (just like you set a file on an imag obj), and this
allows one to use any file that the image loading api can deal
with, setting the loaded image data as the gradient obj's spectrum
"data". It also allows for loading the gimp's 'ggr' grad spectra
files.. I haven't sent any of this, but it's done (actually, the
ggr loader needs redoing as a result of moving to premul data).
I also wanted to add an 'edc' like format for defining
grad spectrums via color stops and give it an extension "esd" say
(for e_spectrum_description). This would allow for specifying
premul color stops and separate alpha stops as well (allowing for
alpha-only grads as a by product). But I never got around to it.
I would then follow the same pattern for edje grad objs
as is now done for edje image objs..
ie. have a 'spectrums' tag which defines the collection of
individual spectra that will be reference..
spectrums {
spectrum: "file1.png";
spectrum: "file2.ggr";
spectrum: "file3.esd";
}
However, I also wanted to be able to have "inlined"
spectrum descriptions via color-stops, in an edje edc file,
as you've done. So I wanted to eventually allow spectrum sources
that were also given via something like
spectrum: "file.edc#name";
where "file.edc#name" would correspond to a defined spectrum with
the given name, in the given edc file.. eg. in the named edc file,
there would be say:
spectrum {
name: "name";
color: ....;
color: ....;
color: ....;
}
Unlike the other spectrum sources, these inlined spectrum
descriptions would not be loaded via an evas grad "file_set" api
function, but the set of color-stops would instead be saved in the
edj-eet file and the grad would be built via the "color_add" api
function.
Note that all but the "png/jpg/other-image-file-type"
spectrum sources would need some modifications to eet, and/or edje,
and/or edje_cc.
Given all this, the grad obj description would then follow
the same pattern as img objs, ie. the gradient tag would then give
reference to a spectrum source
gradient {
normal: "spectrum_source";
}
[[ If possible, could you modify your current inlined set-
of-color-stops-in-the-gradient-tag to a separate inlined spectrum
description referenced-in-the-gradient-tag as described above? ]]
For 'tweening', one would just have the same mechanism
as is now done with images.. put 'tween' after this along with
the spectrum to tween to...
Lastly, there are other gradient specific things like the
geom_type and type_params, and also the spectrum 'offset'. These
would go in each description, inside the gradient tag I suppose...
That's as far as my notes on this go...
However, if you want 'transitions' that are actually able
to interpolate between two grad descriptions, then there are a
couple of issues to deal with:
1. The grad 'type' must be the same (ie. both start and
end grads must be linear, or radial, etc. One could do transitions
between different geometries but it would have to be supported
in evas itself).
2. The 'spread' mode must also be the same, since this
is a discrete set of states.
Now we come to what you are considering: How to interpolate
between two grad descriptions.
Well, I would start about not thinking in terms of sets of
color-stops and instead think in terms of the spectrums..
If you have two spectrums s0,s1:[0,1]-->ColorSpace,
it's easy to see what iterpolating between s0 and s1 means.
For t in [0,1], we have a new spectrum s[t] defined by:
s[t] = (1-t)*s0 + t*s1;
ie. this means that for any f in [0,1], the value of s[t], at f,
is given by
s[t](f) = (1-t)*s0(f) + t*s1(f);
It's then a matter of converting this "abstract" version
to what is needed in practice..
However, doing this would require support for it in evas..
Otherwise it would be somewhat difficult (if the spectra are
inlined but have differing num of stops or distances as has been
mentioned), or very difficult (if the spectra are defined via png
or ggr files).
I hadn't really thought about doing this though...
But it's certainly something worth considering, and possibly
for image objs as well.
jose.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
