Gradients for Xrender

[Lars Knoll]

On Monday 30 May 2005 22:13, Keith Packard wrote:
> On Mon, 2005-05-30 at 19:22 +0200, Lars Knoll wrote:
> > Hi,
> >
> > 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.

Thanks :)

> > 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:
>
> I think I'd rather see this use a new request for each gradient type;
> overriding operands doesn't seem necessary, and that way I think the
> client API will be less error-prone.

I thought about this, and decided, that three requests might be overkill. The 
data to transport over the wire is pretty similar. One could maybe add 3 
methods in the client API if one would want to go for full typesafety, but I 
don't see this as a big problem.

> > The reason for doing it this way is that one gets full support for
> > Gradients as source/mask pictures in all XRender calls. To the client a
> > gradient is just another Picture (though he would get errors if he tried
> > to paint onto it), that can be used in all compositing operations and
> > that can be freed using XRenderFreePicture. At the same time the gradient
> > is independent of the Screen as it doesn't need to hold any data
> > associated with a particular screen.
>
> That's great.  I'd like to figure out how to do something similar with
> image transport so we don't have to have many new compositing requests
> to deal with images.  Perhaps some similar scheme could work...

That's on my list as well. I'd love to be able to have support for compressed 
images in the server. But there the easiest way could be to tie them to a 
Drawable.

I also thought about adding support for Solid fills that do not require a 
drawable (XRenderCreateSolidFill), but since a solution using Drawables exist 
it was less of a priority to me. I could easily add it though; it would 
probably make the Render API a bit more complete and easier to use.

> > The algorithm seems to be reasonably fast. For a full screen (1280x1024)
> > a linear gradient takes about 50ms, a radial gradient 130ms and a conical
> > about 200ms (tested using Xephyr) on my hardware.
>
> You're making my compositing code look pretty bad; I may have to do
> something about that :-)

:-)

> Let's figure out what the right interface is and we can bump the Render
> minor protocol number and get the code into CVS.

Sounds good. The code will need some work to make it into Xorg as well. 
Currently I made sure we don't go through the acceleration hooks if we have a 
gradient somewhere, as some drivers could crash if they find a 0 Drawables on 
a Picture, but in the long term one would want to pass them through and let 
the driver decide if it wants to handle the gradient in hardware.

Cheers,
Lars