Gradients for Xrender

[Lars Knoll]

On Tuesday 31 May 2005 12:20, Owen Taylor wrote:
> On Mon, 2005-05-30 at 22:13 +0200, Keith Packard wrote:
> > On Mon, 2005-05-30 at 19:22 +0200, Lars Knoll wrote:
> > > I had some time over the weekend and added support for gradients to
> > > render.
> >
> > That's cool, and I think the idea of using a picture is really a good
> > one.
>
> I discussed this some with Dave Reveman a few weeks ago, and we were
> thinking that it might make more sense to do something like
> Drawable = {Window,Pixmap} ... have Pattern = {Picture,Gradient}.
> Composite and SetPictureTransform could compatibly be reinterpreted to
> take a Pattern rather than a Picture.
>
> The advantages would be:
>
>  - Would eliminate problems with using a gradient as a target

I don't see that as a real problem. You get a BadDrawable error when trying 
this. The same already happens if you try a Composite request where src and 
dest are on different screens. So the programmer has to know what he is doing 
anyway.

>  - A lot of picture attributes don't make sense for a gradient
>    (filter? graphics exposures? etc.)

But some (as e.g. transformations) do. and graphics exposures don't make sense 
on Pictures that don't wrap a Window neither.

>  - Maybe less confusing in server internals? There are lots of places
>    where pictures are closely tied to being pixel buffer.

Not that many actually. I think I found most of them where this matters. In 
the long term one could probably clean this up even more. 

Also, I don't think that server internals should govern the API/protocol we 
expose on the client side.

> The disadvantage is having to reinvent the wheel for things that are
> shared (repeat, maybe?)

Alltogether I think that using a picture makes the whole API a lot simpler. As 
I explained above the developer has to know some things about the picture 
already now, so the limitation that the created Pictures are readonly is IMO 
not a real problem.

> > > The implementation supports all the gradient types defined in SVG
> > > (linear, radial and conical). What I've done is to extend Render by one
> > > more request:
>
> Does this allow us to do Cairo gradients exactly? The Cairo radial
> gradients have two radiuses for radial gradients. (Maybe you can
> transform the gradient stops)

I have implemented gradients with one Circle and a focal point. But it should 
be trivial to extend the implementation to do two circles. The current one is 
just a special case where one radius is null.

> Where's the specification for conical gradients in SVG? Is this going
> to be new in SVG-1.2?

It's not in SVG as far as I know. It's a nice thing to have nevertheless and 
we support them in Qt 4.

Cheers,
Lars