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

Re: [E-devel] Evas gradients



	Michael Lauer writes:

> Jose,
> 
> all your gradient work is very exciting, however I think
> quite a few people lost track over what we now can do
> with gradients. Would it be too much asked if you could
> tease us with a couple of screenshots laying out the
> new gradient possibilities? All the descriptions are sounding
> really really cool, but my imaginative eye is just lacking
> a bit  ;) 
> 
> Thanks,
> 

	I'm not sure what I could show you "screenshots" of
related to what I recently did with evas gradients.. One was
simply to add support for loading the gimps's gradient spectrums
(or any other kind of file based such description), and the other
was just to move gradient types to being loadable modules.

	If you mean what has been done up to now, then you can
check the evas-test program that comes with evas, it has a few
examples (maybe too many).

	Maybe I should just give a general overview of evas grads..?

	As I've mentioned before at times, the core of what grads
consist of is really just a 1D image.
	Everything that one can do with gradients, one can also
suitably extend to 2D images, and vice-versa.
	For example, the various gradient 'types' can be suitably
realized with 2D images (any conformal mapping of the plane will
give you interesting geometries). Not that evas should do that
with images, just that it can be done.

	One thing that usually makes gradients seem different from
images is that gradients are often defined not by giving explicit
1D pixel data, but rather by giving a sequence of colors at certain
points on an interval -- one generates the 1D pixel data by linearly
interpolating these.

	This could be done with 2D images as well.. and indeed
I've mentioned before things such as 'multi-gradients'. In general,
one finds so-called "procedurally generated textures" of various
kinds, which define 2D images through specifying various parameters.
	In fact, evas' images are actually one such.. It may not
seem like it, but the existance of "borders" actually makes them
into procedurally generated textures (of a fairly simple nature),
the border paramenters are needed in order to fully specify the
final pixel data that gets composited. The svg spec can also be
thought of as a means of specifying such, as can edje's edc format,
or even an evas canvas itself.

	In all that I've done with gradients in evas, I've tried
to highlight this similarity between images and gradients - ie.
to approach them both via a single unified 'texturing' concept,
and reuse whatever evas already had for images.

	Now, besides the existance of esoteric mappings that define
various geometric distributions like one finds with the gradient
'types' (radial, angular,...), one also has simpler coordinate
transformations - eg. linear ones like scaling, skewing, rotating..
or slightly more complex ones like perspective projections.

	The idea is to have these kinds of transformations for
the 'fill' regions of textures -- ie. for both images and grads.
	Right now, evas grads support fill scaling (fill size),
and fill rotating (fill angle), but images only scaling. Adding
fill skewing to grads is only a matter of adding an interface for
this since internally they already allow for it. Adding proj
transform for the fill would involve some additional extensions.
	For images, adding any of these is going to involve
redoing quite a bit of the image rendering internals, and it's
what I'd planned to move on to next.

	When both image and gradient texturing is mature enough,
one can then enable their use as textures to stroke and/or fill
'shape' objects (text, lines, rects, polys,...). This is how
images and gradients are commonly used in things like svg.

	I hope this clears things up somewhat.


   jose.