[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Edje grad objs



On Mon, 31 Jul 2006 15:31:55 GMT "jose_ogp@juno.com" <jose_ogp@juno.com>
babbled:

> 
> > > > 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?

actually nothing that elaborate - simply use pre-drawn h/v/radial gradient
png's and scale them and multiple their rgb color overlayed on solid color
rect :)

> 	But wouldn't this be better left to a more capable, and
> potentially more powerful, e17-background-creation app?

maybe, maybe not - i thought that just providing the horizontal, vertical or
radial gradient (then chose radial position as one of the 4 corners or maybe
center of screen) and then the 2 gradient endpoint colors would be simple
enough, and leave it at that. that should cover most peoples desires for
non-image bg's (also will cover solid color bg which we don't handle). spice up
the image import a bit with a few more options and then we're done. sure -
beyond THAT then would be "out of scope" and be up to a fully fledged bg
creator tool where maybe you can select multiple images and layer them, align
them, etc. etc. etc.

> > > 
> > > 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).

sure. for gl we can use pixelshaders - if available to make gradients fast and
native - i believe there are plans underway to support gradient calculations
natively in xrender (thus accelerate them) but i have not looked into it at all.

> > 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...

though i think priority would be (in order) argb premul, rotation, scaling
fn's, engine api revamp, vgfx :)

> 
> > > 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 :)

nah - not script driven - simply interpolate parameters like x,y or width,
height or rgba etc. etc. - but in this case its interpolating a gradient
spectrum :)

> 	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
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)