Re: [E-devel] [Evas] possible bug in gradient

2008-07-26 Thread The Rasterman
On Wed, 09 Jul 2008 19:33:14 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled:

it's a matter of how high level you want the api. in fact your end api (the
minimal one) is exactly what my original gradient api had.. just add a point a
distance from another with a color - it's linear interpolation. clear it and
re-fill it again when you want to change i. if you want different interpolation
types (logarithmic, etc.) a higher level api can break this down int a series
of linear interp points. the more points - the better the quality. the other
option is to be able to define gradient interp point angles(like defining a
spline curve...) but evas has nothing for that currently... so a simple linear
point api means there is less to worry about... for now :)

but i've never been into gradients. personally. so i am not the one to comment.
i'm no expert nor do i have vested interests. so don't take my comments too
seriously.

  So, if anyone has any comments, suggestions, issues.. *anything* with
  evas gradients -- now would be a good time to pipe in. :)
  
 
  I'd _love_ using gradients, in fact I would use them much more 
  often, _if_ not everytime I start using them, it all feels like I'm 
  operating a powerful machine that has 100s of controls and I don't 
  understand anything.
 
  Perhaps this is an inherent problem from the gradient complexity, 
  but I'd appreciate if we had some documentary material that outlines 
  how to achieve which kind of results, which gradient type to use for 
  what, how many stops for what effect etc. etc.

 
   Ok, let me try and give you a fairly simplified description of what
  gradients are basically about, and how evas tries to deal with this.. 
  for
  better or worse.
 
  ...
  ...
  ...But to get back to the subject at hand here, and 
  before going on to give
  more details on current evas gradients, let me ask you this:
  How would you answer the above two 'general' questions.. or rather, 
  what would
  *you* like to see as an api that would make you want to use gradients 
  more?
 
 
   Not much time to reflect on this? Well, that's understandable :)
  Let me go ahead and review the current set of gradient api funcs in evas,
  give some criticisms, and propose some changes I'd like to make to 
  improve
  things there (and yes, they would break all gradient stuff).
 
   First, recall I mentioned the two parts involved in gradients:
  1) Those aspects related to defining a 1-dim image (or spectrum as I
sometimes call it).
  2) Those aspects related to defining how to map the above to a 2-dim
region - and this covers things like the gradient type, spread-mode,
and such things.
 
   Ok, for (1) in evas we currently have the following (set) api funcs:
 
  void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta);
  void evas_object_gradient_alpha_stop_add(obj, a, int delta);
  void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
  void evas_object_gradient_alpha_data_set(obj, *data, len);
  void evas_object_gradient_direction_set(obj, *data, int direction);
  void evas_object_gradient_offset_set(obj, *data, float offset);
  and also,
  void evas_object_gradient_clear(obj);
 
   The 'clear' api func removes any stops or data that might have been
  set before.
   The 'offset' api func effectively moves the origin of the 1-dim 
  image,
  this is something that as far as I know isn't supported by any vgfx 
  api/spec
  (which is unfortunate since it can give very nice animation effects 
  which are
  otherwise difficult to obtain for some gradient types, eg. radial ones).
   The 'direction' api func just reverses the start/end of the 1-dim,
  and though not directly supported by most vgfx apis/specs, it can be 
  easily
  obtained - it's mostly a simple convenience function.
   The 'color_data' and 'alpha_data' api funcs are to allow for setting
  such a 1-dim image with premul and alpha-only data, rather than going 
  thru
  any kind of procedural description. It's not supported by any vgfx 
  api/spec
  that I know of, not directly anyway.. though you can certainly 
  consider such
  data as an equi-distant set of stops and add it that way (modulo some 
  gymnastics
  with premul data and alpha masks and such).
 
   The 'color_stop' and 'alpha_stop' api funcs evas' current procedural
  descriptions for defining the spectrum -- and these I have real issues 
  with.
 
   Not only is this method of specifying stops not supported by any
  'standard' vgfx api/spec, the use of the int delta as either some kind
  of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and 
  very
  difficult to work with for gui editors and such.
   I propose getting rid of this legacy stuff (inhereted from the 
  equally
  archaic Imlib2 method), and adopt a more standard method.
 
   In fact, let's start from scratch altogether here and let me propose
  a minimal set of 

Re: [E-devel] [Evas] possible bug in gradient

2008-07-15 Thread Jose Gonzalez
  Ok, to continue with my review and critique of evas gradients.. For the
second (2) aspect of these, we have the following api (set) functions:

Evas_Object *evas_object_gradient_add(Evas *e);
void evas_object_gradient_type_set(obj, const char *type, const char 
*instance_params);
void evas_object_gradient_fill_set(obj, Evas_Coord x, Evas_Coord y, Evas_Coord 
w, Evas_Coord h);
void evas_object_gradient_fill_angle_set(obj, Evas_Angle angle);
void evas_object_gradient_fill_spread_set(obj, int tile_mode);
void  evas_object_gradient_angle_set(obj, Evas_Angle angle);

  These were the result of *largely* wanting to extend what evas originally 
had
with gradients to support such things as radial (and other) gradient types, 
'spread'
modes, and various fill geometries, and to do so with minimal changes in what 
was
there to begin with, as simply as possible, and fix some early problems 
encountered
with edje grads, and a couple of other minor reasons.

  The first api func just adds a generic gradient obj to the canvas - as 
was there
from the start.
  The 'type' one allows for setting various types of gradients (linear, 
radial,...)
and any special parameters they might support - it was the simplest way to 
'add' types
of gradients to what was there in evas.
  The 'fill' one is a generic means of specifying a fill geometry for the 
various
types, analogous to what was used for images - it's good for many types of 
gradients
though not always the most natural way to do so for any given type.
  The 'fill-angle' one is a means to rotate the gradient geometry around 
the fill
origin - a very simplified way to add basic transform-like ability.
  The 'fill-spread' one allows for specifying the means to extend the way 
the
gradient is rendered outside the fill region.. you have basic 
repeat/reflect/pad and
some possibly others. It's used by most all vgfx apis/specs that deal with 
grads.
  Lastly, the 'angle' one is a means to specify an initial orientation for 
linear
gradients - was there to begin with and is basically a high-level convenience 
func
to get a kind of alignment 'fitted' to the fill region.


  The 'problem' with these, is basically that they are too restrictive in 
some
ways, not easy to query the state of the vague 'params', and not very intuitive 
for
some grad geometries/types.. nor are they very 'standard'.


  Here's a new api I'd like to propose, a fairly 'standard' one:

  First of all, remove the generic gradient type and have separate api 
funcs
for each type that evas wants to support by default - any subsequent custom 
types
that may be desired can be added as seen fit, or simply via 'object modules'...
something which is needed anyway and not too difficult to add to evas, though 
edje/edc
needs more thought and work to allow for such things.

  Let's say we want linear_gradients, radial_gradients, and possibly
angular_gradients, rectangular_gradients, sinusoidal_gradients, and
maybe such things like triangular ones or star-shaped ones or one that's like
taking the distance to a line, or other kinds.. though all these can be left
as 'modules'.
  We'd then have no more generic gradient type, and have instead:

Evas_Object *evas_object_gradient_[type]_add(e);

where 'type' is any of linear, radial, etc. as desired.

  However, all the api funcs related to specifying spectra on these would
remain the same, as if these gradient types were derived from a generic base
gradient type.

  Then, we'd specify a 'fill' geometry for each type, fitted to that type..
eg. for linear and radial gradients we'd have:

void evas_object_gradient_linear_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
   Evas_Coord x1, Evas_Coord y1);
// set the linear grad geometry from point (x0,y0) to (x1,y1)

void evas_object_gradient_radial_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
   Evas_Coord rx, Evas_Coord ry);
// set the radial grad geometry with center (x0,y0) and radii (rx,ry)

// In both of these, one could use floats instead.

and if more 'fill geometry' related params are needed or desired for the given
type, then they would be additional.. eg, one could have one to set foci for
radial gradients, or an inner_radius, or whatnot.

  We'd then keep the current generic 'spread' api func, but get rid of
both the 'fill_angle' and 'angle' ones.. and instead add one to set a 'fill
transform':

void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t);

where though an 'Evas_Transform' defines a 3x3 matrix for general projective
transformations, for the purposes of transforming such 'fill' geometries, we'd
use only the affine part - this because only affine transforms are supported
for such things by all the vgfx apis/specs.


   In all, for (2) one'd then have:

Evas_Object *evas_object_gradient_[type]_add(e);
void evas_object_gradient_[type]_fill_set(obj, 

Re: [E-devel] [Evas] possible bug in gradient

2008-07-15 Thread Jose Gonzalez

   Again, though not completely to my personal liking (and contradicting 
 my original
 version), I'd like to propose changing the evas gradient 'spectrum' api to 
 be of the form:

 evas_object_gradient_color_stop_insert(grad, r, g, b, a, float pos);

 where the 'r,g,b,a' part of the color-stop is assumed NON-PREMUL.

   Unless there's overwhelming resistance to this, or raster actually 
 shows me
 that software 3D stuff he has from back when, I will change evas grad spectra
 to this form.. and hurt anyone who tries to stop it from being committed. :)

   
 
   And just to quadruple-state my reasons for proposing this:

   I would *prefer* to have (closer to the current version),

 evas_object_gradient_color_stop_insert(grad, r, r, b, a, float pos);
 evas_object_gradient_alpha_stop_insert(grad, a, float pos);

 where the rgba in the color-stop one are assumed premul, and I would also
 keep the 'data' ones,

 evas_object_gradient_color_data_set(grad, *data, len, has_alpha);
 evas_object_gradient_alpha_data_set(grad, *data, len);

   They're far more flexible and consistent with a premul compositing 
 model..

   BUT, the problem with these is that there's NO way to directly implement
 them (in general) with things like xrender, or cairo, or OpenVG,  We'd 
 have
 to do things in software most of the time and create implementation 
 complications
 in general to get some direct support.

   It was a good experiment, and there are people who would like to see 
 this
 kind of thing, but it's likely never going to happen with any of the 
 standards
 or with most libs/apis one could use for engine backends.. :(  Hence, better 
 to
 conform, as this aspect is important.

   Of course this is as far as the premul vs non-premul stops deal. The 
 other
 part of changing to inserting with a float pos rather than adding stops with
 some int delta/distance/whatnot.. is partly in order to also have more direct
 'standard' support, but also to make it somewhat more intuitive.
   
  There is one other option here -- namely to accomodate *both* kinds of
color-stops, premul and non-premul (with no mixing of the two - doing so would
clear the gradient of the former different set of stops or data), so that one
can keep both ways. If an engine backend supports only non-premul stops,
then those are done directly, and one reverts to software for the premul ones.

  So, as a more 'positive' alternative, one may consider:

// premul color-stops api,

evas_object_gradient_color_stop_insert(grad, r, r, b, a, float pos);
evas_object_gradient_alpha_stop_insert(grad, a, float pos);

and also the 'data' ones (the color data premul of course)

evas_object_gradient_color_data_set(grad, *data, len, has_alpha);
evas_object_gradient_alpha_data_set(grad, *data, len);

and also,
// non-premul color-stops api,

evas_object_gradient_color_np_stop_insert(grad, r, r, b, a, float pos);

where of course the 'np' stands for non-premul r,g,b,a.



Hotel pics, info and virtual tours.  Click here to book a hotel online.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nLmLRYlJnF5QRabaPWTj3m9UzpmwX10g1vyCHFScPiHEBcc/

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2008-07-14 Thread Jose Gonzalez
  Let me continue with this evas gradients overview and with my 'critique'
of its current state (largely due both to me and to legacy and other 
constraints),
and to continue proposing *api-breaking* changes.
  Before doing so though, let me quickly point out something to Dave 
regarding
his (really nice) work on adding grad support to edje-editor:  Be careful with 
the
issue of premul vs non-premul color spaces. Edje deals with non-premul color 
stops
for gradients, whereas evas deals with premul color stops and separate alpha 
stops.
You can get the former via the latter easily, but not the other way around.
  If you want to 'input' non-premul color stops, ie. (r,g,b,a, d) where the 
'a'
isn't restricted to satisfy a = r,g,b, like edje does, then in order to emulate
this in evas (currently), you must do:

evas_object_gradient_color_stop_add(grad, r, g, b, 255, d);
evas_object_gradient_alpha_stop_add(grad, a, d);

this is what edje does internally - it's NOT the same thing as:

evas_object_gradient_color_stop_add(grad, r, g, b, a, d);

in fact, this latter will give you some very unexpected results, in general, if 
the
r,g,b,a are indeed non-premul. :)

  It's a shame that all gfx apis/specs that deal with gradients use only the
legacy non-premul approach :(  But it doesn't appear that this is *ever* going 
to
change with any of the standards, or any libs that want to support such 
standards
and little else...
  Hence my suggestion that evas do likewise. It would be the simplest way 
to be
able to have direct support for grads via most engine 'backends' that are 
around.


  Again, though not completely to my personal liking (and contradicting my 
original
version), I'd like to propose changing the evas gradient 'spectrum' api to be 
of the form:

evas_object_gradient_color_stop_insert(grad, r, g, b, a, float pos);

where the 'r,g,b,a' part of the color-stop is assumed NON-PREMUL.

  Unless there's overwhelming resistance to this, or raster actually shows 
me
that software 3D stuff he has from back when, I will change evas grad spectra
to this form.. and hurt anyone who tries to stop it from being committed. :)

  I'll also go over the other half of the evas grad api (ie. related to 
type of
grad, fill geometries, spread modes, and such stuff) a bit later, but any 
comments
on this part from developers, designers, grandmothers, ... would be welcomed.



Explore all of Europe's beauty! Click now for great vacation packages!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nKHLljrNsrAODiA6pFsQs8I4BnXKWo8Vt4B1zhhjjD1aW96/

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2008-07-09 Thread Jose Gonzalez
   I wrote:

 So, if anyone has any comments, suggestions, issues.. *anything* with
 evas gradients -- now would be a good time to pipe in. :)
 

 I'd _love_ using gradients, in fact I would use them much more often, 
 _if_ not everytime I start using them, it all feels like I'm 
 operating a powerful machine that has 100s of controls and I don't 
 understand anything.

 Perhaps this is an inherent problem from the gradient complexity, but 
 I'd appreciate if we had some documentary material that outlines how 
 to achieve which kind of results, which gradient type to use for 
 what, how many stops for what effect etc. etc.
   

  Ok, let me try and give you a fairly simplified description of what
 gradients are basically about, and how evas tries to deal with this.. for
 better or worse.

 ...
 ...
 ...   
  But to get back to the subject at hand here, and before going on 
 to give
 more details on current evas gradients, let me ask you this:
 How would you answer the above two 'general' questions.. or rather, 
 what would
 *you* like to see as an api that would make you want to use gradients 
 more?


  Not much time to reflect on this? Well, that's understandable :)
Let me go ahead and review the current set of gradient api funcs in evas,
give some criticisms, and propose some changes I'd like to make to improve
things there (and yes, they would break all gradient stuff).

  First, recall I mentioned the two parts involved in gradients:
1) Those aspects related to defining a 1-dim image (or spectrum as I
   sometimes call it).
2) Those aspects related to defining how to map the above to a 2-dim
   region - and this covers things like the gradient type, spread-mode,
   and such things.

  Ok, for (1) in evas we currently have the following (set) api funcs:

void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta);
void evas_object_gradient_alpha_stop_add(obj, a, int delta);
void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
void evas_object_gradient_alpha_data_set(obj, *data, len);
void evas_object_gradient_direction_set(obj, *data, int direction);
void evas_object_gradient_offset_set(obj, *data, float offset);
and also,
void evas_object_gradient_clear(obj);

  The 'clear' api func removes any stops or data that might have been
set before.
  The 'offset' api func effectively moves the origin of the 1-dim image,
this is something that as far as I know isn't supported by any vgfx api/spec
(which is unfortunate since it can give very nice animation effects which are
otherwise difficult to obtain for some gradient types, eg. radial ones).
  The 'direction' api func just reverses the start/end of the 1-dim,
and though not directly supported by most vgfx apis/specs, it can be easily
obtained - it's mostly a simple convenience function.
  The 'color_data' and 'alpha_data' api funcs are to allow for setting
such a 1-dim image with premul and alpha-only data, rather than going thru
any kind of procedural description. It's not supported by any vgfx api/spec
that I know of, not directly anyway.. though you can certainly consider such
data as an equi-distant set of stops and add it that way (modulo some gymnastics
with premul data and alpha masks and such).

  The 'color_stop' and 'alpha_stop' api funcs evas' current procedural
descriptions for defining the spectrum -- and these I have real issues with.

  Not only is this method of specifying stops not supported by any
'standard' vgfx api/spec, the use of the int delta as either some kind
of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very
difficult to work with for gui editors and such.
  I propose getting rid of this legacy stuff (inhereted from the equally
archaic Imlib2 method), and adopt a more standard method.

  In fact, let's start from scratch altogether here and let me propose
a minimal set of grdient-spectrum related api functions that more closely
matches what's given by most vgfx apis/specs:

void evas_object_gradient_clear(obj);
// keep this one

void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos);
// where 'pos' is clamped to be in [0,1]. Any previous stop at same pos
// will be overwritten. Must insert one stop at pos 0 and one at pos 1
// to get a valid gradient spectrum.

  This and matches what most use. One could then possibly add the following
funcs to make it easier/more-intuitive to input, query, and manipulate such
gradient stops:

void evas_object_gradient_color_stop_get(obj, int index, *r,*g,*b,*a,*pos);
// get the value of the stop at 'index', where these are ordered from 0 to
// (number_of_stops - 1) according to increasing position. If 'index' is =
// the current number of stops, or index  0, this does nothing.

void evas_object_gradient_color_stop_set(obj, int index, r,g,b,a,pos);
// modifies the r,g,b,a,pos values of the stop at the given index,
// where 'pos' is clamped to lie between the prev 

Re: [E-devel] [Evas] possible bug in gradient

2008-07-09 Thread Vincent Torri

forget my previous mail; it was a problem with my mail client

sorry

Vincent

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2008-07-09 Thread Dave Andreoli
I had worked on the gradient  spectra manager in edje_editor, it is ready now, 
you will see my work in cvs soon.
I have done a cool spectra editor and yes, the 'delta' param is a hell! I agree 
with you also with the rest of the api :)
...but updating all the code that use gradient could be paintfull...
Dave

- Jose Gonzalez [EMAIL PROTECTED] ha scritto:

 I wrote:
 
  So, if anyone has any comments, suggestions, issues.. *anything*
 with
  evas gradients -- now would be a good time to pipe in. :)
  
 
  I'd _love_ using gradients, in fact I would use them much more
 often, 
  _if_ not everytime I start using them, it all feels like I'm 
  operating a powerful machine that has 100s of controls and I don't
 
  understand anything.
 
  Perhaps this is an inherent problem from the gradient complexity,
 but 
  I'd appreciate if we had some documentary material that outlines
 how 
  to achieve which kind of results, which gradient type to use for 
  what, how many stops for what effect etc. etc.

 
   Ok, let me try and give you a fairly simplified description of
 what
  gradients are basically about, and how evas tries to deal with
 this.. for
  better or worse.
 
  ...
  ...
  ...   
   But to get back to the subject at hand here, and before going
 on 
  to give
  more details on current evas gradients, let me ask you this:
  How would you answer the above two 'general' questions.. or rather,
 
  what would
  *you* like to see as an api that would make you want to use
 gradients 
  more?
 
 
   Not much time to reflect on this? Well, that's understandable
 :)
 Let me go ahead and review the current set of gradient api funcs in
 evas,
 give some criticisms, and propose some changes I'd like to make to
 improve
 things there (and yes, they would break all gradient stuff).
 
   First, recall I mentioned the two parts involved in gradients:
 1) Those aspects related to defining a 1-dim image (or spectrum as
 I
sometimes call it).
 2) Those aspects related to defining how to map the above to a 2-dim
region - and this covers things like the gradient type,
 spread-mode,
and such things.
 
   Ok, for (1) in evas we currently have the following (set) api
 funcs:
 
 void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta);
 void evas_object_gradient_alpha_stop_add(obj, a, int delta);
 void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
 void evas_object_gradient_alpha_data_set(obj, *data, len);
 void evas_object_gradient_direction_set(obj, *data, int direction);
 void evas_object_gradient_offset_set(obj, *data, float offset);
 and also,
 void evas_object_gradient_clear(obj);
 
   The 'clear' api func removes any stops or data that might have
 been
 set before.
   The 'offset' api func effectively moves the origin of the 1-dim
 image,
 this is something that as far as I know isn't supported by any vgfx
 api/spec
 (which is unfortunate since it can give very nice animation effects
 which are
 otherwise difficult to obtain for some gradient types, eg. radial
 ones).
   The 'direction' api func just reverses the start/end of the
 1-dim,
 and though not directly supported by most vgfx apis/specs, it can be
 easily
 obtained - it's mostly a simple convenience function.
   The 'color_data' and 'alpha_data' api funcs are to allow for
 setting
 such a 1-dim image with premul and alpha-only data, rather than going
 thru
 any kind of procedural description. It's not supported by any vgfx
 api/spec
 that I know of, not directly anyway.. though you can certainly
 consider such
 data as an equi-distant set of stops and add it that way (modulo some
 gymnastics
 with premul data and alpha masks and such).
 
   The 'color_stop' and 'alpha_stop' api funcs evas' current
 procedural
 descriptions for defining the spectrum -- and these I have real issues
 with.
 
   Not only is this method of specifying stops not supported by
 any
 'standard' vgfx api/spec, the use of the int delta as either some
 kind
 of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and
 very
 difficult to work with for gui editors and such.
   I propose getting rid of this legacy stuff (inhereted from the
 equally
 archaic Imlib2 method), and adopt a more standard method.
 
   In fact, let's start from scratch altogether here and let me
 propose
 a minimal set of grdient-spectrum related api functions that more
 closely
 matches what's given by most vgfx apis/specs:
 
 void evas_object_gradient_clear(obj);
 // keep this one
 
 void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos);
 // where 'pos' is clamped to be in [0,1]. Any previous stop at same
 pos
 // will be overwritten. Must insert one stop at pos 0 and one at pos
 1
 // to get a valid gradient spectrum.
 
   This and matches what most use. One could then possibly add the
 following
 funcs to make it easier/more-intuitive to input, query, and manipulate
 such
 

Re: [E-devel] [Evas] possible bug in gradient

2008-07-09 Thread Jose Gonzalez


 So, if anyone has any comments, suggestions, issues.. *anything* with
 evas gradients -- now would be a good time to pipe in. :)
 

 I'd _love_ using gradients, in fact I would use them much more 
 often, _if_ not everytime I start using them, it all feels like I'm 
 operating a powerful machine that has 100s of controls and I don't 
 understand anything.

 Perhaps this is an inherent problem from the gradient complexity, 
 but I'd appreciate if we had some documentary material that outlines 
 how to achieve which kind of results, which gradient type to use for 
 what, how many stops for what effect etc. etc.
   

  Ok, let me try and give you a fairly simplified description of what
 gradients are basically about, and how evas tries to deal with this.. 
 for
 better or worse.

 ...
 ...
 ...But to get back to the subject at hand here, and 
 before going on to give
 more details on current evas gradients, let me ask you this:
 How would you answer the above two 'general' questions.. or rather, 
 what would
 *you* like to see as an api that would make you want to use gradients 
 more?


  Not much time to reflect on this? Well, that's understandable :)
 Let me go ahead and review the current set of gradient api funcs in evas,
 give some criticisms, and propose some changes I'd like to make to 
 improve
 things there (and yes, they would break all gradient stuff).

  First, recall I mentioned the two parts involved in gradients:
 1) Those aspects related to defining a 1-dim image (or spectrum as I
   sometimes call it).
 2) Those aspects related to defining how to map the above to a 2-dim
   region - and this covers things like the gradient type, spread-mode,
   and such things.

  Ok, for (1) in evas we currently have the following (set) api funcs:

 void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta);
 void evas_object_gradient_alpha_stop_add(obj, a, int delta);
 void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
 void evas_object_gradient_alpha_data_set(obj, *data, len);
 void evas_object_gradient_direction_set(obj, *data, int direction);
 void evas_object_gradient_offset_set(obj, *data, float offset);
 and also,
 void evas_object_gradient_clear(obj);

  The 'clear' api func removes any stops or data that might have been
 set before.
  The 'offset' api func effectively moves the origin of the 1-dim 
 image,
 this is something that as far as I know isn't supported by any vgfx 
 api/spec
 (which is unfortunate since it can give very nice animation effects 
 which are
 otherwise difficult to obtain for some gradient types, eg. radial ones).
  The 'direction' api func just reverses the start/end of the 1-dim,
 and though not directly supported by most vgfx apis/specs, it can be 
 easily
 obtained - it's mostly a simple convenience function.
  The 'color_data' and 'alpha_data' api funcs are to allow for setting
 such a 1-dim image with premul and alpha-only data, rather than going 
 thru
 any kind of procedural description. It's not supported by any vgfx 
 api/spec
 that I know of, not directly anyway.. though you can certainly 
 consider such
 data as an equi-distant set of stops and add it that way (modulo some 
 gymnastics
 with premul data and alpha masks and such).

  The 'color_stop' and 'alpha_stop' api funcs evas' current procedural
 descriptions for defining the spectrum -- and these I have real issues 
 with.

  Not only is this method of specifying stops not supported by any
 'standard' vgfx api/spec, the use of the int delta as either some kind
 of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and 
 very
 difficult to work with for gui editors and such.
  I propose getting rid of this legacy stuff (inhereted from the 
 equally
 archaic Imlib2 method), and adopt a more standard method.

  In fact, let's start from scratch altogether here and let me propose
 a minimal set of grdient-spectrum related api functions that more closely
 matches what's given by most vgfx apis/specs:

 void evas_object_gradient_clear(obj);
 // keep this one

 void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos);
 // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos
 // will be overwritten. Must insert one stop at pos 0 and one at pos 1
 // to get a valid gradient spectrum.

  This and matches what most use. One could then possibly add the 
 following
 funcs to make it easier/more-intuitive to input, query, and manipulate 
 such
 gradient stops:

 void evas_object_gradient_color_stop_get(obj, int index, 
 *r,*g,*b,*a,*pos);
 // get the value of the stop at 'index', where these are ordered from 
 0 to
 // (number_of_stops - 1) according to increasing position. If 'index' 
 is =
 // the current number of stops, or index  0, this does nothing.

 void evas_object_gradient_color_stop_set(obj, int index, r,g,b,a,pos);
 // modifies the r,g,b,a,pos values of the stop at 

Re: [E-devel] [Evas] possible bug in gradient

2008-07-09 Thread Toma
While everyones talking about gradients, Ive a request... Id like to
be able to create a gradient that goes from sollid white to alpha then
clip an image to it so that the image fades away. Something like
this...

spectra {
  spectrum {
name: sp2;
color: 255 255 255 255 1;
color: 0 0 0 0 1;
  }
}
collections {
group {
   name: Test;
   parts {
  part {
 name:  base;
 type:  GRADIENT;
 mouse_events:  0;
 description {
state:default 0.0;
gradient.spectrum: sp2;
fill.spread: 1;
 }
  }
  part {
 name:  chinaman;
 mouse_events:  0;
 type:  IMAGE;
 clip_to:   base;
 description {
state:default 0.0;
image.image: ChinaManBeard.jpg COMP;
image.normal: ChinaManBeard.jpg;
 }
  }
   }
 }
}

In this example I was trying to get this image to fade like the
gradient does. If you clip the image to a normal RECT then fade the
clip box it will fade the image too.
Would be nice, but not essential. Im guessing the mechanics behind it
are alot more complex than I comprehend...
Toma

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2008-07-09 Thread Jose Gonzalez
   Toma wrote:

 While everyones talking about gradients, Ive a request... Id like to
 be able to create a gradient that goes from sollid white to alpha then
 clip an image to it so that the image fades away. Something like
 this...

 spectra {
   spectrum {
 name: sp2;
 color: 255 255 255 255 1;
 color: 0 0 0 0 1;
   }
 }
 collections {
 group {
name: Test;
parts {
   part {
name:  base;
type:  GRADIENT;
mouse_events:  0;
description {
   state:default 0.0;
   gradient.spectrum: sp2;
   fill.spread: 1;
}
   }
   part {
name:  chinaman;
mouse_events:  0;
type:  IMAGE;
clip_to:   base;
description {
   state:default 0.0;
   image.image: ChinaManBeard.jpg COMP;
   image.normal: ChinaManBeard.jpg;
}
   }
}
  }
 }

 In this example I was trying to get this image to fade like the
 gradient does. If you clip the image to a normal RECT then fade the
 clip box it will fade the image too.
 Would be nice, but not essential. Im guessing the mechanics behind it
 are alot more complex than I comprehend...
 Toma

   

  This is something very useful and indeed I would like to add this
ability to evas. I would add this as the ability to mask any object by
either an image or gradient object.
  I *don't* want to add it via the current clipping mechanism. Why?
Because I implemented just that sometime back and ran into several semantic
and practical 'issues' that I truly don't like. I'd leave clipping as is -
clip to rectangles and ignore any transforms, corners, whatnot these objs
might have.. ie. a pure rectangular display region clipping mechanism.

  The separate mask approach allows for a simpler, easier to optimize,
directly supported by most engines, and gives a powerful method since the
mask objects (images or gradients) can be transformed and/or filtered.
With it, you can get all the nifty 'new' reflection stuff that apple's
made famous recently, and a lot more such masking effects (eg. mask with
a buffer evas, indirectly, by masking with the associated image).

  NB: This is somewhat similar to (though not exactly the same as)
fill and/or stroke texturing of vgfx objs with image or grad objects.



Click to become a designer and quit your boring job.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7MABetj9UMyNeM7OIM8bHr74HKPatHWDUwfP2rv45TmoDt/

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2008-06-26 Thread Jose Gonzalez

 So, if anyone has any comments, suggestions, issues.. *anything* with
 evas gradients -- now would be a good time to pipe in. :)
 

 I'd _love_ using gradients, in fact I would use them much more often, _if_ 
 not 
 everytime I start using them, it all feels like I'm operating a powerful 
 machine that has 100s of controls and I don't understand anything.

 Perhaps this is an inherent problem from the gradient complexity, but I'd 
 appreciate if we had some documentary material that outlines how to achieve 
 which kind of results, which gradient type to use for what, how many stops 
 for what effect etc. etc.
   

  Ok, let me try and give you a fairly simplified description of what
gradients are basically about, and how evas tries to deal with this.. for
better or worse.

  There are really two independent aspects to gradients:

1. A 1-dim image of possibly variable length.
2. A means of mapping this image onto a planar region to create a 2-dim image,
   and this is what's often wrapped under the term of the 'type' of gradient,
   as well as other things such as the 'repeat-mode' and other stuff.


  For (1), there are multitudes of ways one can use to define such a 1-dim
image, and everyone has their own idea of what a simple, or natural, or 
powerful,
or whatever favorite way. Often, this is given in a 'procedural' way and 
involves
specifying some set of colors strung out along some abstract line element. One
then interpolates 'in-between' the given colors to obtain the full 1-dim image
of colors.
  One common method for such a description is eg. what's specified in the
svg spec, namely one gives a sequence of colors and positions on the [0,1]
interval. Imlib2 allows one to specify a sequence of colors and some abstract
'distance' to the next color. Evas has something similar but the distance
is more like a 'weight' for that color. The Gimp allows one to define some
sequence of colors together with the position of the 'half-way' color (or some
such, I can't recall anymore), and allows for various kinds of interpolation
in-between (linear and some others). There are others as well.
  So you see, there are any number of ways to 'specify' what the 1-dim
image is to be, abstractly or not, and in evas I went ahead and just allowed
you to give a 1-dim image as well, in case you don't want to bother with some
procedural representations.

  In general, we may ask: What should be the kinds of such descriptive means
that evas should support for defining the 1-dim image (or 'spectrum' as I've
sometimes called it) that one needs for gradients?

  Now, for (2), there are again any number of means by which one can map
a 1-dim image onto a planar region, but a common one used is to give a function
float f(float x, float y)  which is used roughly as follows: for input (x,y)
let r = f(x,y), and somehow pick a color on the 1-dim image that corresponds
to this r.
  For example, a linear gradient corresponds to any number of linear
functions of x, y, eg. anything of the form f(x,y) = a*x + b*y; will define a
'linear gradient'. Similarly, a radial gradient can be defined by the function
f(x,y) = sqrt(x*x + y*y); or similar quadratic functions of x,y. An angular
gradient can be defined by atan2(y,x); a rectangular gradient by the func
f(x,y) = max(|x|,|y|); an 8-pointed star gradient can be defined by
f(x,y) = (1 + 1/(4-2*sqrt(2)))/2 * min((1 / sqrt(2))*(|x|+|y|), max (|x|,|y|));
a sinusoidal gradient by f(x,y) = y - sin(a*x);  and the list is of course
endless.
  The thing about many of these functions is that the values r = f(x,y)
can vary arbitrarily, and one wants the gradient to be somehow 'fitted' to a
given planar region it can minimally fill (thus effectively determining the
range of the 1-dim image), hence one needs to map those values of 'r' to be
within the range of the 1-dim image. This is what gives rise to the various
repeat (or extend, or spread) modes.. things like repeat/reflect/pad/...

  Given this infinite flexibility as to gradient types and the various
kinds of 'geometries' that those implicitly define, people often tend to
pick one or two common ones and define separate apis for the particulars
of those geometries. For example, for linear gradients people often expose
something like the linear gradient from point p0 to point p1, or the
radial gradient centered at point c and of radius r, and similar such
specialized things - one set of api funcs for each gradient 'type'.

  In general, we may again ask: What should be the descriptive methods that
evas should support for defining the 'types' of geometric mappings that one
wants for gradients?

  What's in evas right now (and also part of the latest proposal on having
another method of defining gradient spectra) is one attempt to answer these
two questions subject to certain constraints:

a) Retain some flexibility - eg. one can define new gradient types easily, and
   pass parameters much in 

Re: [E-devel] [Evas] possible bug in gradient

2008-06-25 Thread Jose Gonzalez
   Vincent wrote:

 Hey,

 before putting that in bugzilla, here is what I obtain with the following 
 code:

 [code]

o = evas_object_gradient_add (evas);
evas_object_gradient_fill_angle_set(o, 90);
evas_object_gradient_fill_spread_set(o, 1);
evas_object_gradient_fill_set(o, 0, 0, w, h);
evas_object_gradient_clear(o);
evas_object_gradient_color_stop_add(o,
255,
0,
0,
255,
2);
evas_object_gradient_color_stop_add(o,
0,
255,
0,
255,
2);
evas_object_resize(o, w, h);
evas_object_image_fill_set(o, 0, 0, w, h);
evas_object_move (o, 10, 10);
evas_object_show (o);
 [/code]

 the result:

 http://www.maths.univ-evry.fr/pages_perso/vtorri/files/gradient_bug.png

 that is, there is a red vertical line at the left of the gradient, while 
 that line should be at the right (imo)

 is it a bug ?

 Vincent
   

  Since we've been dragged back into gradient land recently, I went ahead
and 'fixed' this 'bug' and a few other minor such grad things. But before
finishing with this, I thought I'd mention an aspect of grads that people might
feel needs improving - namely, the issue of how to specify 'stops'.
  A common, or 'standard', way to do this is by defining a color (or alpha)
stop to be a color (or alpha) plus a 'position' in [0,1], not like the current
description of stops. This might be a better method for defining gradient stops
in both a visually intuitive sense, and for creating gui widgets to 
interactively
create grads/stops.

  Now, one could replace evas' current method with this, or one could extend
evas to support this by adding an api func of the form:

void evas_object_gradient_color_stops_set(obj, Evas_List *stops);

where here 'stops' would be a list of Evas_Gradient_Color_Stop defined as 
something
of the form  { int r,g,b,a;  float pos; }  where pos is constrained to lie in
[0,1].
  Similarly, one could have a 'get' func to return the list of previously
set such stops. The semantics would be that no copying is done in either set/get
so if one changes the values of some set of stops then one'd need to re-set them
again or one may not trigger an update (and btw, this also holds for the current
'data' set method).
  There's a further option here with this - namely, one could take the 
r,g,b,a
in the color-stop def to be non-premul, or keep as premul and also have separate
alpha-stops as is now done, ie. also have an Evas_Gradient_Alpha_Stop of the 
form
{int a; float pos;} and set/get such a list of alpha stops.

  So, if anyone has any comments, suggestions, issues.. *anything* with evas
gradients -- now would be a good time to pipe in. :)



Click here for great computer networking solutions!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMRKoGF8NN0xr9D572Uk2zb0l4dgt7e5fHRu1AuxxDgFh/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2008-06-25 Thread Michael 'Mickey' Lauer
[...]

 So, if anyone has any comments, suggestions, issues.. *anything* with
 evas gradients -- now would be a good time to pipe in. :)

I'd _love_ using gradients, in fact I would use them much more often, _if_ not 
everytime I start using them, it all feels like I'm operating a powerful 
machine that has 100s of controls and I don't understand anything.

Perhaps this is an inherent problem from the gradient complexity, but I'd 
appreciate if we had some documentary material that outlines how to achieve 
which kind of results, which gradient type to use for what, how many stops 
for what effect etc. etc.

-- 
:M:

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2008-06-25 Thread Jose Gonzalez
Michael 'Mickey' Lauer wrote:
 [...]

   
 So, if anyone has any comments, suggestions, issues.. *anything* with
 evas gradients -- now would be a good time to pipe in. :)
 

 I'd _love_ using gradients, in fact I would use them much more often, _if_ 
 not 
 everytime I start using them, it all feels like I'm operating a powerful 
 machine that has 100s of controls and I don't understand anything.

   

  Well, I kind of feel the same way about everything really. I'd say
that the role of a gfx lib like evas is to provide a good amount of gfx
flexibility without sacrificing speed or quality, and to do so via a
reasonable api.

  In the end though, I think there's really no better way to deal with 
gfx stuff than via higher-level ibs/apis that simplify and narrow
things down.. and ultimately, one really needs a good gfx gui-designer.


 Perhaps this is an inherent problem from the gradient complexity, but I'd 
 appreciate if we had some documentary material that outlines how to achieve 
 which kind of results, which gradient type to use for what, how many stops 
 for what effect etc. etc.
   

  That would be useful, sure. There's really not much to 'gradients'
themselves really, and I'll try to quickly go over some basic aspects a bit
later, but as far as to how/when/why to use them... that's a bit nore
open-ended and really brings us back to the above remarks about the need
for gui tools and some experience with gfx design - and a bit more from evas
than it can currently use gradients for.




Click for information on the top Adult Education programs. Advance your career. 
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNbXVhW5GIOV27WPtuh1WWK2e9FFXzRNTc3fL776n0nqfB9/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Evas] possible bug in gradient

2007-12-27 Thread [EMAIL PROTECTED]

Vincent wrote:

 before putting that in bugzilla, here is what I obtain with the
 following code:
 
 [code]
 
   o = evas_object_gradient_add (evas);
   evas_object_gradient_fill_angle_set(o, 90);
   evas_object_gradient_fill_spread_set(o, 1);
   evas_object_gradient_fill_set(o, 0, 0, w, h);
   evas_object_gradient_clear(o);
   evas_object_gradient_color_stop_add(o, 255, 0, 0, 255, 2);
   evas_object_gradient_color_stop_add(o, 0, 255, 0, 255, 2);
   evas_object_resize(o, w, h);
   evas_object_image_fill_set(o, 0, 0, w, h);

How did that last line sneak its way in there. :)

   evas_object_move (o, 10, 10);
   evas_object_show (o);
 [/code]
 
 the result:
 
 http://www.maths.univ-evry.fr/pages_perso/vtorri/files/
 gradient_bug.png
 
 that is, there is a red vertical line at the left of the gradient,
 while  that line should be at the right (imo)
 
 is it a bug ?

I would say it is a bug. If you have a chance to look into
it, please do so Vincent. I probably won't be able to look at it
for several days at least.

   jose.

_
Click here for free information on nursing degrees, up to $150/hour
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nEnkqsCC5gFaXv4Ikwr77eXJ1Awq2LPpIvUf2DraNworXcs/



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel