[cairo] Path Gradients

[Bobby Salazar]

I'm afraid that everyone is searching for the perfect solution to this and everyone's idea of a perfect solution is different, and so it will never move past discussions. Unfortunately, I know very little about graphics and shading algorithms or I might try to implement it myself. That is why I think a bounty may help.

I've spent some time surfing the net and researching the GDI+ path gradients and it is actually far more complex than what I'm after. But it does allow very advanced gradients to be created. I especially liked the 2-color bell gradient concept (explained in the first link below). Here are some web pages that I found especially informative about GDI+ path gradients:

http://weblogs.asp.net/frank_hileman/archive/2004/10.aspx
http://weblogs.asp.net/frank_hileman/archive/2004/09.aspx
http://www.devx.com/dotnet/Article/32848/0/page/4
http://functionx.com/vcnet/gdi+/gradientbrush.htm
http://www.bobpowell.net/pgb.htm

I guess what I'm really looking for is a way to get a "path-shaped" gradient from a given center point to the edges of the (current) path. Where the gradient would use the color stops to produce the colors out to the edge of the path. I'd be interested in a more capable implementation of path gradients eventually, but I doubt I would ever use it due to the complexity. So a simple path, color stops and center point is what I'm really after, as seen in these images (except for the triangle in the last one):

http://samples.gotdotnet.com/quickstart/winforms/doc/PathGradient.jpg
http://www.java2s.com/Code/VBImages/PathGradientBrushesDiamondRectangleCirlceandquad.PNG


Perhaps we could implement a "simple" path gradient initially that takes a center point and produces a gradient shape from the current path and color stops, and work on a more advanced implementation later? I think that this "simple" path gradient already fits very well into the pattern and color stop framework cairo already provides.


> -----Original Message-----
> From: spitzak at thefoundry.co.uk
> Sent: Sat, 22 Dec 2007 19:08:43 -0800
> To: jose_ogp at juno.com
> Subject: Re: [cairo] Path Gradients
> 
> 
> On Dec 21, 2007, at 1:28 PM, jose_ogp at juno.com wrote:
> 
>> 
>> 	Behdad wrote:
>> 
>>> Humm, meshes in general would have made much more sense in cairo
>>> if it supported projective transformations.  What's people's insight
>>> about that?  Am I right that Xrender supports them?  What about
>>> PS/PDF/SVG?
>> 
>> 	"Meshes" would need a suitable definition, but rectangular
>> and/or triangle meshes would likely be a welcome addition. Xrender
>> initially played around with "triangle fans and strips", but it seems
>> that never made it very far(?).
> 
> Unfortnately too much data is not a simple mesh. There needs to be a
> method to draw a completely arbitrary connected graph of points.
> 
> My recommendation is to add some way to indicate that the current path
> edge is going to be drawn adjacent to another filled object with the
> exact same path edge. This would allow Cairo to remain thinking about
> single fills, and a single transform of the source image per fill.
> 
> The biggest problem with my idea is that points must be sent many
> times, for a triangle mesh the point would be resent for every
> triangle. Now Cairo is not going to be used to draw games, so this may
> not be a problem. But if it is, there will probably have to be a way to
> send a whole set of points once, and then index into this set when
> building the paths.
> 
> There is also a lot of desire to say "this point should get this x+y
> coordinate from the source pattern, or this value from the gradient".
> Technically this can be achieved with the current Cairo api, but it
> involves a lot of really ugly math, and seems to be the sort of thing
> that Cairo should do for you.
> 
>> 	I'm not sure why you feel that meshes would make 'more sense'
>> with projective transforms..?
> 
> I believe he means that we need projective transforms for source
> patterns. This is needed to distort a texture map to match the mesh,
> and produce images that look like 3d renders.
> 
> Anything else having to do with 3D can be done by code calling Cairo by
> transforming the 3D position to the correct 2D screen positing before
> passing it to Cairo.
> 
>>  As far as projective transforms go, there
>> are certain "issues" you'd have to deal with because such transforms
>> don't - in general - preserve lines, or quadratics, or cubics... thus
>> making their use as transforms of "paths" somewhat problematic.
>> 	Not to mention that transforms are often used via sampling in
>> an 'inverse' way.. and such transforms, while their 3x3 matrices may
>> be invertible, may not in effect be invertible when used as transforms
>> acting on 2D coordinates.
>> 	It is possible to do things in a 2-step process, wherein one
>> could apply an affine transform on paths and a projective one on the
>> rasterized result - ie. first transform back via the projective one,
>> and then work 'as usual' in that coordinate system.
> 
> Quadratics and Cubics are preserved through perspective transformations
> if you use interpolate homoginized coordinates (ie where there is x,y,w
> for the projected point, and the resulting point on the screen is x/w,
> y/w. Interpolate the x,y, and the w according to the cubic and it will
> be projected correctly).
> 
> My biggest problem with making Cairo do 3D is that as currently defined
> it is useless. Supposedly the pen and font are always transformed by
> the current transform. This would mean that any projected path would be
> equivalent to drawing that path using the current pen in 2D and then
> pespective transforming the resulting surface. This is trivial to do by
> using a seperate surface (and pretty much impossible to achieve in any
> other way). A far more useful result is to draw the resulting path with
> a fixed-size pen, this is also much easier to implement. This is the
> main reason why I want to see Cairo changed so that the pen and font
> are fixed in device space at the moment they are set, rather than being
> modified by further transforms.
> 
> There is also problems with the path object in that there is no way to
> cleanly add a z or w to the points. It should instead be a 1-d list of
> ops alternated with coordinates, and the ops have an argument in them
> indicating how many numbers are provided. This would also be more
> compact than the current representation.
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo

____________________________________________________________
Receive Notifications of Incoming Messages
Easily monitor multiple email accounts & access them with a click.
Visit http://www.inbox.com/notifier and check it out!